All of lore.kernel.org
 help / color / mirror / Atom feed
From: Morten Shearman Kirkegaard <moki@fabletech.com>
To: mlmmj@mlmmj.org
Subject: Re: PATCH: Access priority
Date: Tue, 16 Feb 2010 16:52:51 +0000	[thread overview]
Message-ID: <1266339171.9646.134.camel@mopo-laptop> (raw)
In-Reply-To: <4B5D7A55.4090302@yahoo.com.au>

On Mon, 2010-01-25 at 22:02 +1100, Ben Schmidt wrote: 
> The problem is that if you have a list that is 'moderated' or
> 'modnonsubposts', the 'allow' access keyword is ineffective, but
> behaves like 'moderate'. This patch fixes that so that access rules
> have priority, and do what they say.
> 
> I think this is more intuitive.

Since we now have the "moderate" keyword, then maybe you are right. It
made more sense when it was just "allow" or "deny." Maybe "moderate"
should have been "hold" or something like that.

> Do others agree? Or could this change cause problems?

It would break backwards compatibility on a major feature, so I don't
want to include it in the 1.2-series.

I also think change this needs a bit more thought. I've tried to graph
the flow as it is in mlmmj now, and what I think you are proposing.
Please correct me, if I misinterpreted your text - I did not look into
the code patch.

The "moderation" boxes represent the "moderated" and "modnonsubposts"
tunables.


In mlmmj now:

   +--------+ deny   +--------+
   | access |------->| reject |
   +--------+        +--------+
allow |  | moderate
      |  +-----------+
      v              v
+------------+    +------+
| moderation |--->| hold |
+------------+    +------+
      |              |
      v              |
   +------+          |
   | send |<---------+
   +------+


Proposed flow:

allow +--------+ deny   +--------+
+-----| access |------->| reject |
|     +--------+        +--------+
|         | moderate
|         v
|   +------------+    +------+
|   | moderation |--->| hold |
|   +------------+    +------+
|         |              |
|         v              |
|      +------+          |
+----->| send |<---------+
       +------+


Pros: With the proposed flow, it is possible to force a mail through via
an access rule. The keywords might also make more sense to the
administrators.


Cons: With the proposed flow, it is impossible to force a mail to be
held for moderation. If a list is modnonsubposts, but the administrators
would like a chance to examine multipart mails, before they are sent to
the list, it can be done like this today:

moderate ^Content-Type: multipart/
allow


One possible solution - at least to the bypass moderation problem -
might be to add another keyword. We could add "send" to force the mail
past normal moderation procedures.

A possible new flow:

 send +--------+ deny   +--------+
+-----| access |------->| reject |
|     +--------+        +--------+
|  allow |  | moderate
|        |  +-----------+
|        v              v
|  +------------+    +------+
|  | moderation |--->| hold |
|  +------------+    +------+
|        |              |
|        v              |
|     +------+          |
+---->| send |<---------+
      +------+

send ^X-Password: 90e85684b1285a9f$
moderate ^Content-Type: multipart/
allow

I know it does not fix the meaning of "allow" vs. "moderate" on lists
which are also subject to regular moderation, but I don't see a way to
do that without breaking backwards compatibility.

Any thoughts on this?

Morten

-- 
Morten Shearman Kirkegaard <moki@fabletech.com>
CTO, FableTech
http://fabletech.com/





  parent reply	other threads:[~2010-02-16 16:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-25 11:02 PATCH: Access priority Ben Schmidt
2010-01-25 13:41 ` Ben Schmidt
2010-02-16 16:52 ` Morten Shearman Kirkegaard [this message]
2010-02-16 21:40 ` Ben Schmidt
2010-02-16 22:03 ` Franky Van Liedekerke
2010-02-17  8:21 ` Mads Martin Jørgensen
2010-02-17 21:40 ` Morten Shearman Kirkegaard
2010-02-17 22:56 ` Franky Van Liedekerke
2010-02-18 10:39 ` Morten Shearman Kirkegaard
2010-02-18 14:27 ` Ben Schmidt
2010-02-18 15:15 ` Morten Shearman Kirkegaard
2010-03-09 22:32 ` [mlmmj] " Ben Schmidt
2010-04-10 19:52 ` Morten Shearman Kirkegaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1266339171.9646.134.camel@mopo-laptop \
    --to=moki@fabletech.com \
    --cc=mlmmj@mlmmj.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.