message handling for publish actions via container tab

[Clemens Robbenhaar]

I split off an issue from the "email functionality in workflow" issue95,
which will (most propably) not be fixed in the current release.

 I simply nosed in the people from issue95.

The current implementation of the messaging in case of status changes
via the Containers publish tab is quite suboptimal; this is due to a
design flaw from an earlier version, which did not take the messaging
into account.

 Despite one can change the publication state of multiple contents via a
containers publish tab in an uniform way, these changes are broken up
into separate actions, one for each content object, passed separately
from the UI to the application level, and then need to be assebled back.

 Actually there has been made a considerable effort not to send one
seperate message per content object and status update, but still the
result does not make me happly.

 Basically the mailed message should look like:

From: <email address hidden>
Sender: <email address hidden>
Subject: Your versions are approved
To: <email address hidden>

Objects:
 http://www.bar.tld/content1
 http://www.bar.tld/content2
 http://www.bar.tld/content3
 http://www.bar.tld/content4
[...]
Message:
  Bulk approval via the publish tab.

and not have a separate Object/Message combination for each slot.

 The current implementation passes the approval message to each of the
versions, which in turn pass them to the service_message. This allows
to store the message in the versions, too (which has been the primary
goal if the previous implementation w/o email notification).

 I propose to do this the other way round: store all the necessary
information about the status change in some "StatusTransaction" object
e.g. created by the service_message, and then "commit" this transaction.

 The service_message then can assemble the necessary emails from
the transaction object, and do different things with them, like
storing the message in the version objects, sending mails to different
affected people, or maybe something completely different.

 Looking at the spam I created in my mailbox when testing this feature,
I could guess of implementing another kind of "service_messages",
wich dies not send mails but maintians a "ToDo" list in the ZODB for the
user; the user e.g. can then click on the list of messages stored there
and look what is actually to be done. The 'service_messages' may purge
'todo' items form th list, if the aprropriate status chnage has been
done by the user (or maybe someone else ;-).

 Ok, ok, this is just one of my wild ideas, which propably will never be
realized, at least not by me.
 However the current implementation makes the implementation of such an
alternative messaging system nearly impossible. Thus it maybe makes
sense to have this more flexible, I guess

 Sorry for writing such a long mail, as I only had to make such a small
issue to discuss. Just after a day of nitty-gritty hacking/testing I
feel the irresistible ned to write soem scifi about neat vapourware ;-)

[Kit Blake (kitblake)]

> Looking at the spam I created in my mailbox when testing this feature,
> I could guess of implementing another kind of "service_messages",
> wich dies not send mails but maintians a "ToDo" list in the ZODB for the
> user; the user e.g. can then click on the list of messages stored there
> and look what is actually to be done. The 'service_messages' may purge
> 'todo' items form th list, if the aprropriate status chnage has been
> done by the user (or maybe someone else ;-).

There's space in the (new) footer for a ToDo list link :)

[Martijn Faassen (faassen)]

Sounds like a nice feature. I suggest storing this
information in the member object.

Another way might be to catalog versioning information
and query on it.

If Clemens takes this one up we may get it in 0.9.2, if
not, then we'll worry about it later.

[Clemens Robbenhaar (crobbenhaar)]

I will first try to clean up the insane code caused by the design flaw,
that caused the MessageService not know the bulk commit actually trigges
N-times the same message to be mailed.

 I will post some idea how to fix it before I do any progress on this
issue. Well, have to see when I find the time ...

[Clemens Robbenhaar (crobbenhaar)]

1.5 month ago I promised to send more ideas how to fix the current
problem. Well, here it is:

 The current flow of the messages on approvbla looks like:

   --------------------
   | |
   | tab_status |
   | |
   --------------------
         (1)|
            |
            | request status change
            |
         (n)|
   --------------------
   | |
   | Versioning.py |
   | |
   --------------------
         (n)|
            |
            | create messages
            |
         (1)|
   --------------------
   | |
   | service_messages |
   | |
   --------------------
            |
            V
    SMTPlib sends messages

To make this work, one needs an additional "send_pendig_messages"
call from the tab_status_ to the service_messages

Instead of creating the messages in the separate Versioning objects,
something else may perform the actual action, including assembling the
messages to be mailed. I think this "something else" should not be the
tab_status (would store application logic in the ui) and not the
service_messages (which should only send messages, nothing else).

 Thus I propose to define a new service, say "service_approval".
("service_workflow" seems to be a little too sophisticated, actually the
service does not allo to define new workflows.)

This would look like:

   --------------------
   | |
   | tab_status |
   | |
   --------------------
            |
            |
            | request status change
            |
            |
   -------------------- --------------------
   | | (1) (n)| |
   | service_approval |--------------------| Versioning.py |
   | | changes status | |
   -------------------- --------------------
         (1)|
            |
            | create message
            |
         (1)|
   --------------------
   | |
   | service_messages |
   | |
   --------------------
            |
            V
    SMTPlib sends message

 Now to implement a different notification mechanism than sending
emails around, one could:

  - implement a different approval service
    which treats the approval notification completely different

  - extend the member object to store information
    what kind of notification this person wants
    and change the approval service to either store
    the notifications in the member object or mail it
    (or both, maybe)

some more random remarks:

 Storing the pending requests in the Member object would have the
drawback that all pending requests have to be assigned to some single
Member, which is currently the nearest ChiefEditor. This may create a
bottleneck.

 Maybe cataloging and querying this information from somewhere may be a
better idea, as this preserves the information even if the object moves.
However I have little to no experience with catalogs yet and do not feel
very sure about howe to handle this.
 Th...

[Martijn Faassen (faassen)]

Shifting this debate into 0.9.3 land.

[Martijn Faassen (faassen)]

Deferring this. Clemens, let me know when you want to work on this.

[Martijn Faassen (faassen)]

Moving to 0.9.4.