just wanted do write a variant of the folder_listing view that sorts items descending by their effective date (to automatically get the newest ones on top)
i thought using effective would be better than using created because this way users can also influence the sort order manually.
however, i noticed that effective is not set for the content items at all. (single state workflow with state private)
would it do any harm to set the effective date to the creation date of an item when it gets created by default in plone?
(in fact i think this used to be the case in plone 4.2 or earlier 4.3 releases - but i might be wrong)
it still can be re-set when publishing the content item.
you are now trying this on Plone 5 but it doesn't seem to work the same way as in Plone 4.X ?
you expect the effective date to be set and equal to creation date when the object is created, but effective_date should be updated/refreshed automatically when an object is published? (I remember reading this a while ago on a page about date on www.plone.org, older help content)
I agree @frisi here. Single state items not having effective date is a problem, as there is no one good field to sort on for mixed content. Last modified might not be appropriate, and creation date will be wrong for content that have workflow and a different publish time from creation time.
You can fix this yourself by having a event listener and setting it for the one state workflow items, but I think we should change the way this works in Plone by default.
@jaroel:
collections are ok if you need upside down sorting for some folders.
in my case i'd need to train the editors to work with collections and they'd need to create collections as default view for 50+ existing folders.
this is why i chose the add-a-new-view-template route.
@fredvd:
i'm trying this on plone4.3.9 and did not try 5 at all.
the effective date gets updated when an item is published already - which is fine.
the new (and i thinks this used to be the case at some point in time) thing is: set effective date to creation date for new objects instead of leaving it empty.
@agitator:
could you please elaborate what you consider tinkering on this proposal peter?
IMO this should be a PLIP, even if it's just a small one with a small implementation.
But a change on what is stored in metadata like the effective date could have some side effects and should be discussed - this discussion being a start.
If you can find evidence, that your proposed behavior was the default with Archetypes in Plone < 5, that would definitely help accepting a PLIP.
From a technical perspective I'm +1 on storing a value other than None for effective date (and also expiration date): Products.ZCatalog > 3.1 / ZODB 4 doesn't accept None values anymore.
From a content management perspective I'm -1 on this idea, because if no expiration or effective date is explicitly specified, it shouldn't be set automatically. For example, you cannot distinguish anymore, if it was intentionally set or not.
I agree that it is problematic to have in some cases effective date not set.
I do not agree to magically give the creation date as effective date. That is semantically wrong.
For non-workflowed items the effective date is in fact the parents effective date, because they inherit permissions from the nearest parent and so they inherit the time of publication from the parent.
This would need to index all non-workflowed children (and their children, in case of non-workflowed folderish content) when an item is published. Since this might be expensive we should really be careful with this.
It should be possible to switch indexing off. Easiest is probably to provide a behavior like IInheritedEffectiveDateswhich can be added or removed to/from non-workflowed items.
Subscribers and indexers then need to take care to do their job when the parent is published or a non-workflowed item is added to a published container.
This need to be discussed anyway and is a behavioural change in Plone which I would like to see PLIPed too.
Yes, this is what we did at EEA. We use content rules to set effective date for one-state-workflow items to the creation date. We had lot of issues with one state content that didn't have effective date.
I am not in favour of having the effective date equal to creation date by default. The effective date is semantically coupled to a workflow transition to a "final public state". Plone workflow is very flexible but doesn't have the notion of a single final public state, there can be multiple final states. In most case one of those final states represents the " published state" where you would also automatically make sure the effective date is set properly. At EEA we had to create custom packages for this concept eea.workflow anf eea.progressbar for plone4 though. Maybe it helps.
