Fix a write on read situation #2
Conversation
|
I'd add a short comment why its twice inside the block to the code. |
gforcada
force-pushed
the
write-on-read
branch
from
229f5c5 to
e63cd64
Compare
|
@jensens done and added a changelog entry. Let's test it: plone 4.3: http://jenkins.plone.org/job/pull-request-4.3/139/ |
If the context gets its first annotation it need to be marked as safe to write. The same goes for the annotations on the object.
gforcada
force-pushed
the
write-on-read
branch
from
e63cd64 to
0cd8e3c
Compare
|
Second try: plone 4.3: http://jenkins.plone.org/job/pull-request-4.3/141/ |
|
No worth trying anymore, they need plone.protect > 3.x ... So, yet another one that needs to go together with plone/buildout.coredev#131 |
|
The version of plone.protect in buildout.coredev (4/5) needs to be increased? |
|
@jensens for Plone 5 it could be merged, but then we will have to make a branch without these changes for Plone 4 as there plone.protect is still pinned at 2.0.2. The relevant PR to add plone.protect 3.0.x on Plone 4.3 is plone/buildout.coredev#131 Everything I gathered so far (related to plone.protect 3.0.x on Plone 4.3) is on that pull request, see the +150 errors that jenkins reports... |
|
buildout.coredev branch 4.3 pins to plone.protect 2.0.2 because of https://plone.org/products/plone-hotfix/releases/20151006 we need to go to 3.0.14 anyway in 4.3. |
|
Looks fine but I'd advise to use a conditional import of safeWrite if it is available. Or, require versions of plone.protect where safeWrite is available in setup.py. |
jensens
added
35 needs: rebase
22 status: in-progress
and removed
21 status: confirmed
labels
|
superseeded by #3 |
The rule assign manager is initialized as soon as you open the rules tab thus making a write on read.
It's hard to properly fix this as plone.contentrules is mostly the engine and the one that adds/removes/changes the rules is plone.app.contentrules...
Ideas welcome. See a follow up pull request that partially fixes the problem on plone.app.contentrules