RE: Dada Bridge w/moderation enhancements

 
From: "Dave Leffler" <dleffler@PROTECTED>
Date: May 11th 2009

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

  • This mailing list is a public mailing list - anyone may join or leave, at any time.
  • This mailing list is a group discussion list (unmoderated)
  • 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:

https://dadamailproject.com/d

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:

  • Constructive critiques on the program (I like, "x", but, "y" needs some work - here's an idea on how to make this better...)
  • Bug/Error reports
  • Bug fixes
  • Request For Comments on any changes to the program
  • Help customizing Dada Mail for your own needs
  • Patches
  • Language Translations
  • Support Documentation/Doc editing, FAQ's, etc.
  • Discussion of any changes that you would like to be committed to the next version of Dada Mail -

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.

Privacy Policy:

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.