Fwd: [Product-Developers] Re: Review of a branch that should make CMFEditions and collective.indexing work together peacefully

Patrick Gerken do3ccqrv at googlemail.com
Wed Feb 24 15:19:01 UTC 2010

On Wed, Feb 24, 2010 at 14:09, Andreas Zeidler <az at zitc.de> wrote:
> On 22.02.10 16:54, Patrick Gerken wrote:
>> Hi,
> hi patrick,
>> I have created a test case and a change in behavior that fixes the issue.
>> Instead of comparing the modified date of new and old object, I check for the
>> _p_changed attribute. That is a rather drastic change but adding an
>> assertion in
>> the change to compare old modification check vs new modification check
>> showed that both yield the same results in all test cases when used without
>> collective.indexing.
> great.  could you please elaborate a bit more on what the problem was
> here, though?

With CMFEditions configured to always create new versions with a save,
the first save will not create a new version, and subsequent saves loose
the change Comment, and they do not store the modified object as a new
version, but the object before the modification.

You can reproduce it by modifying the new test case:

If you uncomment that line of code, the tests will fail.
If you want to see the resulting faulty page, you can start the zope server
during the tests with Zope.Testing.ZopeTestCase.utils.startZServer
It will return hostname and port

Debugging script python is hard, if they get called from
CMFFormController double so.
So here is somewhat complicated explanation of what happens in the background:

CMFEditions has at least two scripts hooked into the CMFFormController, that
get executed when executing edit actions. One script gets called
before the actual
edit, one after.
The script that gets called before the edit seems to be for finding
new files, since
it will create a new version with the comment hard coded to "Initial commit"

1. Object creation
New version gets created, even with the version commit entered on the Add Form
2. First edit of object.
The second script calls the modified method on both the context, and the latest
version stored by CMFEditions. The date returned by the modified method is
updated during reindex. collective.indexing delays the actual reindex until some
pre commit hook. This hook is executed long after the request. As a result,
the script does not see any difference, and does not create a new version
3. Any subsequent edits of objects
The FIRST script notices that the object was modified. It also
compares the modified
dates, and the modified dates of the last object in version storage
and the context
differ, because the edit that happened earlier did not trigger a new
version to be saved
but updated the modified date. This script thinks now, that this is a
new file, and stores
a new version with the version comment "Initial comment".

>> I would be rather grateful if somebody with a bit of
>> collective.indexing knowledge could have
>> a look at it, maybe there is a better way than the one I implemented.
>> My changes are in the do3cc_collective.indexing branch.
> i can have a look on friday, but i'm not sure i'm on top of the
> CMFEditions part.  i'm cc'ing alec in the hope he might be able to join
> the tuneup? :)

I will at least be available in the plone chat.

Best regards and thanks,


More information about the Product-Developers mailing list