message handling for publish actions via container tab
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Silva |
Confirmed
|
Wishlist
|
Sylvain Viollon |
Bug Description
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://
http://
http://
http://
[...]
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 ;-)
Changed in silva: | |
milestone: | none → 3.0.1 |
assignee: | Clemens Robbenhaar (crobbenhaar) → Sylvain Viollon (thefunny) |
milestone: | 3.0.1 → 3.1.0 |
> 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 :)