OK, I think I'm "git"ing it :) I believe I've (finally) successfully "forked" dada-mail on github http://github com/dleffler/dada-mail/tree/feature-subscriber_editable_fields and I'm guessing I should work with the "feature-subscriber editable fields" branch? I've also cloned my fork to my (Vista) computer using TortoiseGit
I'm learning git, and am pretty sure I can easily push and pull from my fork, but not sure the best route to get my changes to you
Also based on my git reading thus far, I think I could've cloned your git repository to my computer and then pushed changes to you? The only fallback, is that my changes wouldn't be online and readily accessible?
Dave Leffler
-----Original Message----- From: Justin J [mailto:justin@dadamailproject com] Sent: Sunday, May 10, 2009 18:20 To: [list_settings list_name] Subscriber Subject: [dadadev] RE: Dada Bridge w/moderation enhancements
On May 10, 2009, at 3:51 PM, Dave Leffler wrote:
>
These mods are probably more of a kludge or a quick "proof-of- concept," rather than a refined solution applicable to universal application;
at least at this point
OK - noted
If you're 're interested, we should really get you a
branch/fork on github, so that coordinating all the diffs is easier
The branch I'm currently working on is taking forever to finish and is
going to cause conflicts if you try to use the master as a base for
the Dada Bridge changed
I may just merge it and be done with it, once
the code, again, settles down to some stability
I may branch again and have a, "phase 2" on the Subscriber profiles
stuff, so everyone doesn't have to wait on me
I'm experimenting with coding the following mods (primarily to the dada_bridge plugin) and value any feedback, especially on the concept/design
- Adding the "digest" feature using another category of subscribers
(list, authorized_sender, digest, moderator)
That would be wonderful
You may want to see if there's an RFC on
digests and the formatting
The current extension for digests doesn't
follow it ;)
-- Probably would set the digest timing interval by list rather than
by subscriber/profile
That would probably save you some sanity :)
-- I assume that in general a "digest" subscriber would only be
different in they wouldn't receive individual (approved) posts, only the
compilation? E g, if the digest were set to 7 days, regular "subscribers" would
receive individual messages, but the "digest" subscriber would receive one compilation of all posts from the past 7 days every 7 days
I think you're right
You may want to do some research and see what
other popular MLM's are doing - even something like Google Groups
Hopefully, with the profile stuff I'm attempting to finish :) It'll be
easy for a subscriber to change their pref
on if they want to be
subscribed to a digest sublist, or not
I assume the sender should NOT be allowed to moderate their own
message (as you wrote below), UNLESS they are allowed to send messages to
the list without moderation? Makes sense to me, just not coded yet!I'll work on a non-login method to approve/reject awaiting
messages, but am a little concerned about creating a security problem I do have a specific and immediate need for this feature
Not to worry - I've made the changes for these two issues, here:
http://github com/justingit/dada-mail/commit/8c918ab095908c434d5ec2c58d61deb 913cabe1a
sorry for the formatting changes - I usually run PerlTidy between your
changes and what I have - it seems to make the diff program work a
little easier
-- Trying to think through the logic of having to add a name to the subscriber, authorized sender, and moderator lists
A name?
-- In theory, are authorized senders just additional list admins?
Starts getting into roles/tasks;
I think when I made the feature - no they weren't, they were simply a
list of other email address that could send a message to the mailing
list - and which wasn't the list owner
This mostly makes sense when
you have announce-only lists, but there's a few people in an
organization that want to send out to that list
Happens all the time
in small businesses, I think
(right?)
how does a list admin differ from an authorized sender from a moderator
I almost don't want to open up this can of worms yet, but it is
another feature lacking in Dada Mail
For now, I think authorized
senders aren't going to fill any sort of list administration tasks,
yet - except, perhaps the moderation stuff
The security model in
Dada Mail needs a well-deserved overhaul
It dates back to almost the
beginning of 2
0
Works well for the simple model that was made, but
it's not worth shoe horning anything more on there
Start a new thread, email: dadadev@dadamailproject.com
This is the developer discussion mailing list for Dada Mail.
If you are just looking for support Dada Mail, consult the message boards at:
https://forum.dadamailproject.com
Documentation for Dada Mail:
Specifically, see the Error FAQ:
https://dadamailproject.com/d/FAQ-errors.pod.html
To post to this list, send a message to:
mailto:dadadev@dadamailproject.com
All subscribers of this list may post to the list itself.
Topics that are welcome:
Dada Mail is on Github:
https://github.com/justingit/dada-mail/
If you would like to fork, branch, send over PRs, open up issues, etc.
This Privacy Policy is for this mailing list, and this mailing list only.
Email addresses collection through this mailing list are used explicitly to work within this email discussion list.
We only collect email addresses through our Closed-Loop Opt-In system.
We don't use your email address for any other purpose.
We won't be sharing your email address with any other entity.
Unsubscription can be done at any time. Please contact us at: justin@dadamailproject.com for any help regarding your subscription, including removal from the mailing list.
All mailing list messages sent from us will include a subscription removal link, which will allow you to remove yourself from this mailing list automatically, and permanently.
All consent to use your email address for any other purpose stated at the time of the mailing list subscription will also be revoked upon mailing list removal.