Ticket #9256 (closed PLIP: fixed)
Expand variable substitution in mailing action of plone.app.contentrules
Reported by: | smcmahon | Owned by: | smcmahon |
---|---|---|---|
Priority: | minor | Milestone: | 4.0 |
Component: | Content Rules | Version: | |
Keywords: | Cc: | lucmult@…, plip-advisories@…, xMartin |
Description
Proposed by
Steve McMahon
Seconded by
Matthew Wilkes
Motivation
Consider an e-mail notification sent of workflow state change. What's the thing that the person receiving the email is likely to want to know first (after title and URL)? The new state.
There are several other bits of metadata that might be similarly useful: who's the creator, who's making the change, etc. Integrators who want to use the content rule infrastructure for notification emails can't reuse the mail action for complex, site-specific notifications; they must currently write a new action. Assumptions
That a compent architecture lookup to convert the values does not introduce a performance penalty greater than the flexibility it offers justifies. Proposal
- Survey metadata fields and determine which are appropriate for inclusion (i.e. fields that might be generally useful)
- Modify the current implementation of mailer to allow for specially fields strings to trigger adapter lookups against the event that caused them
- Convert the current tag implementations to very simple adapters
- Vet for security issues in exposing more information by default
- Improve test coverage to ensure undefined variables fail safe, like the current implementation
- Document in the interface and Plone.Org documentation.
Implementation
This is close to trivial. The adapters should adapt the appropriate event and context that triggered the content rule and return an IVariableContent (or similar) which is then used to replace the string that triggered it. Deliverables
Updates to plone.app.contentrules/actions/mail.py. Update to user interface for content-rules management to make it clear what substitutions are available, and how they're used. Unit tests to prove implementation fails safe, and that we respect localisation where possible/appropriate in our default implementations. Risks
Complication of user interface for content-rules management. It is also assumed that anyone currently using content rules is not using strings of the form ${changenote} &c. in their emails, and expecting those strings to be returned not interpolated. If that is incorrect some emails would return the incorrect content.
More modular
Posted by xMartin at Apr 15, 2009 11:02 AM Good idea since I needed this myself. I added the site name to the variables.
Would it be possible to find a more modular approach that allows variable substitution for multiple actions so that you don't have to copy all that code from the mail action if you write your own to use the same variables? For example there is collective.contentrules.mailtolocalrole which I couldn't use because I needed other variables.
Work already done?
Posted by Steve McMahon at Jun 02, 2009 06:10 PM The guts of this may already be done:
http://pypi.python.org/pypi/collective.contentrules.mail/
If that's suitable, this could just be a proposal for core integration.
Change History
comment:4 Changed 7 years ago by albieback
+1
Plone is almost a point-and-click workflow-based-application platform. E-mail notifications is a must for this to be complete.
comment:6 Changed 7 years ago by pupq
The most common questions I get in classes when we look at content rules involve the crippled mail feature we ship with. Replacing it with collective.contentrules.mail would be a huge +1 (or replacing with some other product that provided similar, common cases).
comment:7 Changed 7 years ago by erikrose
- Owner smcmahon deleted
Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)
comment:9 Changed 7 years ago by davisagli
- Owner set to smcmahon
Resetting owner to smcmahon since he already said he can own it.
My FWT vote: +1.
comment:10 Changed 7 years ago by MatthewWilkes
I'm going to abstain as I helped draft the PLIP. Steve, I'd be happy to help implement, btw.
comment:11 Changed 7 years ago by miohtama
Just to note:
collective.easytemplate already has rich templating support for content rules emails. Instead of pulling out just some set of strings it exposes the full Archetypes context to the outgoing email. I don't believe there is point to limit exposed fieldset to some subset, because Plone and Python world has rich templating capabilities to pull out any variables from the context. If we follow Zope AccessControl rules (expressions go through RestrictedPython) we shouldn't be able to expose any sort of security breach here.
http://plone.org/products/easy-template
So from my point of view the problem falls to category how to "templatize" any action or context in any Plone user interface element. There already exists the historical implementations for putting TAL conditions on CSS etc. but due to its limitations it hasn't catched fire.
comment:12 Changed 7 years ago by rossp
FWT vote +1.
comment:13 Changed 7 years ago by raphael
FWT vote: +1
comment:14 Changed 7 years ago by calvinhp
FWT Vote: +1 an excellent addition to an already powerful feature in Plone.
comment:15 Changed 7 years ago by esteele
Approved by FWT vote.
comment:18 Changed 7 years ago by smcmahon
comment:19 Changed 7 years ago by smcmahon
comment:20 Changed 7 years ago by smcmahon
comment:21 Changed 7 years ago by smcmahon
comment:22 Changed 7 years ago by smcmahon
comment:23 Changed 7 years ago by smcmahon
comment:24 Changed 7 years ago by smcmahon
comment:25 Changed 7 years ago by smcmahon
comment:26 Changed 7 years ago by smcmahon
comment:27 Changed 7 years ago by davisagli
comment:28 Changed 7 years ago by optilude
IMHO, using plone.indexer for substituions would be a dangerous mixing of concerns. Mandating a change to the way indexers are registered would be unnecessary change as well.
Maybe there could be some kind of bridge component from indexer to string substitution, but relying on it as a default seems wrong to me.
comment:29 Changed 7 years ago by optilude
comment:30 follow-up: ↓ 31 Changed 7 years ago by ldr
Is there any reason not to use string.Template here for the substitutions?
Template strings (python standard library)
comment:31 in reply to: ↑ 30 Changed 7 years ago by smcmahon
Replying to ldr:
Is there any reason not to use string.Template here for the substitutions?
Assuming there's not too much overhead in using a lazy lookup instead of a mapping, I can't think of any.
comment:32 Changed 7 years ago by esteele
Your PLIP has passed the Framework team's initial review. Feel free to discuss any suggested changes either here in the PLIP ticket or on the mailing lists. Final deadline for this PLIP is set for September 30.
comment:33 Changed 7 years ago by smcmahon
comment:34 Changed 7 years ago by smcmahon
comment:35 Changed 7 years ago by smcmahon
comment:36 Changed 7 years ago by smcmahon
comment:37 Changed 7 years ago by smcmahon
comment:38 Changed 7 years ago by smcmahon
Ready to merge.
comment:39 Changed 7 years ago by davisagli
comment:40 Changed 6 years ago by rossp
FWT vote: +1 for merge
comment:41 Changed 6 years ago by esteele
This PLIP has been accepted for merging into Plone 4.0
The final vote was: Alec Mitchell +1 David Glick +1 Erik Rose +1 Laurence Rowe +1 Matthew Wilkes - Ross Patterson +1
Please merge your branches into the Plone 4.0 head by end-of-day Friday Oct 16. If you need assistance with merging, please contact me.
We'll be assigning a documentation ticket to this PLIP shortly. Please assist the docs team in documenting the changes and new features that this PLIP introduces.
comment:42 Changed 6 years ago by esteele
Please assist the doc team in creating/updating documentation relating to this PLIP. See #9604.
comment:43 Changed 6 years ago by smcmahon
comment:44 Changed 6 years ago by smcmahon
comment:45 Changed 6 years ago by smcmahon
Merge complete.
comment:46 Changed 6 years ago by esteele
- Status changed from assigned to closed
- Resolution set to fixed
+1
I have used collective.contentrules.mail in some case.
+1 to integrate collective.contentrules.mail.
BUT, it miss some aspect, like localization, example, I need the review state localized (in all my cases). I had problems to no-ASCII data, but I don't sure that the problem was in collective.contentrules.mail.
A addition that I feel can be good, is a way to add a Field (or attribute) in mail, like ${attr:myField}.
Another aspect is who will receive the mail, today is based in LocalRoles, but it's mix LocalRoles and GlobalRoles (setted in Plone root), if the content don't acquire the Roles/Permission, the collective.contentrules.mail, still use the GlobalRoles.
In Roles subject, now it allow use: Owner, Reader, Editor and Reviewer, but what about customized role ? This is a minor question IMHO, but those roles are hardcoded that isn't a good thing IMHO.
It is a important feature to we at Simples Consultoria, we have been using it a lot! :-)