Products.cmfplone: automatically transition expired items to a new "expired" state

[tkimnguyen]

re discussion in https://github.com/plone/Products.CMFPlone/issues/1577 this is about

• adding a new "expired" state to the simple publication workflow
• automatically transitioning a content item to the "expired" state when its expiry date has been reached

[djay]

To do this you need some kind of timer.
One thing we were thinking of doing is adding a special kind of content
rule to collective,cron which delays actions until a date. The date can
come for the content. For example,
You create a content rule with the action to set the workflow state to
expired. The trigger will be on content change but you add another action
between the trigger and the workflow change called a delay action. This
will delay your expire actuon until the expiry time is reached.
This mechanism would be useful for all sorts of things like sending emails
at publication time, sending reminders to an owner 1d an event starts etc.

On Thu, 26 May 2016, 11:02 PM T. Kim Nguyen [email protected]
wrote:

re discussion in #1577
https://github.com/plone/Products.CMFPlone/issues/1577 this is about

• adding a new "expired" state to the simple publication workflow
• automatically transitioning a content item to the "expired" state
  when its expiry date has been reached

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/plone/Products.CMFPlone/issues/1604

[jensens]

have a look at https://github.com/collective/collective.wfeffectiverange

[jensens]

this one would need to go through PLIP process, since it would be a immersive change.

[gforcada]

A PLIP for adding async framework of the sorts, should be a foundation PLIP for this one, I would say is high time for plone to integrate some async mechanism in the core

[tkimnguyen]

@jensens yup, this should be a PLIP. https://github.com/collective/collective.wfeffectiverange is awesome.

[djay]

@tkimnguyen I think generalizing it into a content rule action/condition would make it an even better PLIP. So it's not limited to changing content state or acting on just publish or expiry dates.

[djay]

for example the content rule could be

Trigger: content modified
Action1: delay further actions until Published date
Action 2: change state to Published

or perhaps its possible to implement as a condition

Trigger: content modified
Condition: Start date == now-2days
Action: send email to owner.

[davilima6]

I'm not sure we want this. It means adding complexity for all current distributed workflows. For the default Simple Workflow instead of 3 states, we'll have 4 to wrap our users' head around (at least +33% in complexity not counting the new associated transitions, guards etc). And the addition is of a different, new sort, because time-based. In the same manner the Single State Workflow won't be single anymore...

I think the content rule strategy is less invasive - and also makes more sense since it's a transition that will be triggered regardless of source state - but it could be even better if we turn the effective/expired date into a behavior which comes disabled by default. What do you think? That way we don't make users think® ("is expired a state, is it not?") - at least not until they decide to make use of additional functionality.

[jensens]

At Framework Team meeting we first found this is formal not a PLIP. Please use the PLIP template and follow the process. This then needs much more detailed explanations.

Overall feeling in the team is that the auto-transition is not something we would like to see in core, because it makes workflow much more complex. This is perfect as an addon.

We agree that the original idea to reduce toolbar clutter and combine expiration and workflow in one could be followed and pliped.

[tomgross]

We use https://github.com/collective/collective.autopublishing/tree/master/collective/autopublishing for this task. It has a very nice and flexible GUI and email notification.
I'm -1 to have this in core. We should decide one addon and put some good documentation around it.

[jensens]

@tomgross well, c.autopublishing does it different. So I see room for both, dependent on the use case. and yes, this another indicator for not pushing such a feature to the core.
I'd moreover like to see basic infrastructure like cron and taskqueue in core, so implementing and supporting this kind of features is easier

[tomgross]

@jensens Even for the cron-like behavior there are at least options:

• https://github.com/collective/Products.cron4plone (more a GUI for integrators)
• https://github.com/collective/collective.timedevents (more an API for developers)
  Both are thin layers on top of the existing time server of Zope.

[djay]

and https://pypi.python.org/pypi/collective.cron

[tkimnguyen]

thx @jensens and @plone/framework-team - I wanted this issue to be for discussion, and the end result would be a PLIP. Your feedback that this probably shouldn't be in core is what I was looking for (one way or the other). I'm ok if you want to close this issue.

[gforcada]

Well, at least some docs should be written about what are the recommended add-ons for achieving this non-core functionality... :-)