Ticket #9529 (confirmed Bug)

Opened 7 years ago

Last modified 3 years ago

Condition expression bug in Resource Registries on migrated instances

Reported by: piv Owned by:
Priority: major Milestone: 4.x
Component: Backend (Python) Version: 3.3
Keywords: Cc: piv

Description

In case of migration of plone instance from 3.2 version (ResourceRegistries 1.4.3) to plone 3.3 version (ResourceRegistries 1.5.3) entries in resource registries (after very first cooking) starts to behave incorrectly.

The problem was indirectly introduced in this commit: [23701].

Here I'll try to explain why resources are cooked with bad (empty) cooked_expression on migrated plone instances.

Cooking process creates new resources by coping from original ones. And of course cooked_expression is not copied as it didn't exist previously, but copy method of resource class will set cooked_expression to expression with compiled empty string (starting point which causes the problem). Afterwards when condition expression is evaluated registry firstly looks if cooked_expression exists (for performance reasons) by calling getCookedExpression method:

def getCookedExpression(self):
        # Automatic inline migration of expressions
        if 'cooked_expression' not in self._data:
            expr = Expression(self._data['expression'])
            self._data['cooked_expression'] = expr
        return self._data['cooked_expression']

Here we can see that getCookedEpression will never re-set cooked_expression attribute. It only set it up in case this wasn't done before.

To workaround the issue I had to loop through the all registries resources and manually re-set expressions (using setExpression resource's method) and cook resources afterwards.

This problem could be resolved in two ways: 1. resorce's init method shouldn't set empty cooked_resource attribute, or 2. getCookedExpression method should look into cooked_expression and compare it's text with original expression, in case they aren't equal it'll re-compile cooked_expression.

Change History

comment:1 Changed 6 years ago by hannosch

  • Owner changed from hannosh to hannosch

comment:2 Changed 6 years ago by hannosch

  • Owner hannosch deleted

I won't find the time or energy to look into this - un-assigning myself so it's clear someone else should tackle this.

comment:3 Changed 4 years ago by kleist

  • Status changed from new to confirmed
  • Version set to 3.3
  • Component changed from Infrastructure to Backend (Python)
  • Milestone changed from 3.3.x to 4.x

Still an issue in Plone 4?

Note: See TracTickets for help on using tickets.