"Copy to present" button doesn't drop _v_ attributes

Bug #649605 reported by ChrisW on 2010-09-28
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zope 2

Bug Description

...which results in this buggy behaviour:

- edit a page template

- edit it again

- go to the history tab, and use the "Copy to present" button to bring
back your first edit.

On the edit tab, you will correctly see the text you brought back.
However, if you render the template, the old text will be used.

It's only if you "Save changes" that the copied-to-present text will
actually be used.

Marius says this is because the precompiled TAL bytecode is sitting there in a
_v_program attribute that's not stored in the ZODB, so it's not reverted
when you undo things.

How to fix? Make the "Copy to present" button drop all _v_* attributes
from the object it modifies.

This is OFS.History.Historical.manage_historyCopy, right? Quick
untested patch:

--- ./OFS/History.py.orig 2010-09-28 02:11:56.535745440 +0300
+++ ./OFS/History.py 2010-09-28 02:12:00.043764683 +0300
@@ -151,6 +151,9 @@
             base = aq_base(self)
             base._p_activate() # make sure we're not a ghost
             base.__setstate__(state) # change the state
+ for attr in dir(base):
+ if attr.startswith('_v_'):
+ delattr(base, attr)
             base._p_changed = True # marke object as dirty

Changed in zope2:
importance: High → Medium
ChrisW (chris-simplistix) wrote :

Er, thanks for your assessment Hanno, but this is a confusing and uncalled for regression.

That ranks as High to me...

Changed in zope2:
importance: Medium → High
Hanno Schlichting (hannosch) wrote :

Sorry, as the release manager I reserve myself the right to judge importance for the project.

Something that only affects one rarely used ZMI screen and has a known workaround isn't of high priority.

Changed in zope2:
importance: High → Medium
ChrisW (chris-simplistix) wrote :

Rarely used is a matter of opinion.
I have customers who use this frequently, day in, day out.

I'm glad to see that you're keeping your Plone bent away from your judgements relating to Zope 2 - not! ;-)

ChrisW (chris-simplistix) wrote :

Okay, here's a test which demonstrates the problem.
It likely belongs in src/OFS/tests/testHistory.py

ChrisW (chris-simplistix) wrote :

Here's the monkey patch I use to fix the problem.

It's based on the discussions in this thread:

Colin Watson (cjwatson) wrote :

The zope2 project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope2.

Changed in zope2:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers