Add "reallymodified" index

[buchi]

In plonesocial, add a boolean index that is True for a true modification, False for a reindex that was triggered not by an edit of the context object itself but of a child object. That is: if you add a plone.app.discussion reply to a page it's Modified date index is updated, but the "reallymodified" index is False. Implementation conform the pattern outlined in this thread: event listener marks creation event path on request, second event listener on modified checks this flag.

http://plone.293351.n2.nabble.com/IObjectModifiedEvent-object-modified-or-added-td6630019.html

[gyst]

Thomas, I've come to realize that the Boolean approach we discussed contains a bug. It wil obscure "real" edits on the container object that happened before a child addition triggered the boolean flag. That is, given a page which was edited 10 minutes ago, when adding a plone.app.discussion reply to that page, then using a boolean index will flag the whole page object as "not really edited" which will obscure the previous real change in the activity stream.

Solution: instead of a Boolean index, use a DateIndex "edited" which is like "modified" but only gets updated on real edits of the object, not on ContainerModifiedEvents triggered by child object addition. Given a document that was really edited 10 minutes ago, when adding a plone.app.discussion event to that document, then the "edited" index should return not "now" but "10 minutes ago".

I've updated the wiki for this.

Products.ATContentTypes.tests.events.txt may be informative.

[gyst]

Instead of maintaining state variables on REQUEST, this can also be done by having a global handler instance that subscribes to both IObjectCreated and IContainerModified. Such a handler can maintain private state to keep track of what's going on. The actual indexers for date (#3) and userid (#2) can then use some accessor on this handler object to determine whether or not to update the index. As I've said in #2, we need to ensure consistency between the userid and date indexes for "really modified".

[buchi]

Yes, I came to the same conclusion when thinking about it again.

I think we should add something like an "activityDate" which will get updated when an activity occurs that should be shown in the activity stream, e.g. editing or publishing a content item.

I guess we will have to store the activityDate on the content object. If we store it only in an index, we loose the information on reindex or on a catalog rebuild.

This raises the question how to store the activityDate. Do something on our own, like storing it in an annotation or an attribute or provide a schemaextender for AT and a behavior for DX? I'm slightly favoring schemaextender/behavior right now.

To have a consistent userid for the activityDate we should also store the userid of the actor and not depend on the last modifier.

[gyst]

This boils down to the need to have a changelog on all content objects. And then have indexers for date and userid that are able to extract the "really changed" userid and "really modified" date.

We should be able to reuse existing versioning/history stuff in Plone for the changelog facility per-object. So this should be generic Plone, not PloneSocial. The only PloneSocial stuff we need is the indexers for date and userid. Given appropriate accessors on the per-object changelog, that should be straightforward. Maybe this should be done in collective.lastmodifier, priming that code for a PLIP on both date and userid for "real" changes.

[buchi]

It makes sense to have this in a separate package, e.g. collective.lastchange or collective.changlog I don't like to use collective.lastmodifier for this because of it's naming the last modifier should be consistent with the modification date.

Maybe this addon should store a complete changelog instead of just storing the date and user of the last change. Plone already has some history support. Currently the history viewlet displays the workflow history combined with the revision history if versioning is enabled. In the case when versioning is enabled, we already have all needed information needed in the revision history. If versioning is disabled, we need to store an additional history log containing add and edit operations.

It would also make sense to plip this for inclusion into Plone because if versioning is disabled the history contains just workflow changes, which is not really what you would expect.

Having a (complete) content history, it should be straight forward to implement appropriate indexers for our use case.

[gyst]

Additionally I think it's a good idea to also have the workflow changes in there. Especially since this can trigger that an object is accessible and shows up in some user's activity stream for the first time.