[Erp5-dev] Username lost when installing a Person object from bt5 file

[Ivan Tyagov]

Hi,

I encountered the following bug:
When a 'Person' object is contained inside a business template file and
this Person object has set an username ('reference' property) after
installing this bt5 file this properly is set to 'None' and thus it's
not a valid ERP5 user. What happens is that in business template
installation 'manage_afterClone()' is applied to every installed object
including 'Person' which is fine.
But the default behavior for 'Person' is to reset reference in
'Person_afteClone()'.
Because manage_afterClone() --> Person_afterClone() chain is normally
called when a Person object is copied/pasted and by exception when a
business template is installed I would like to introduce this patch that
will restore 'reference' when a 'Person' objects is installed from bt5
file.
Any ideas how this can be done in a more elegant way/place are welcome.

Ivan

Index: Document/BusinessTemplate.py
===================================================================
--- Document/BusinessTemplate.py (revision 11920)
+++ Document/BusinessTemplate.py (working copy)
@@ -646,8 +646,14 @@
obj = obj._getCopy(container)
container._setObject(object_id, obj)
obj = container._getOb(object_id)
+ default_reference = getattr(obj, 'default_reference', None)
obj.manage_afterClone(obj)
- obj.wl_clearLocks()
+ if obj.meta_type in ('ERP5 Person',) and default_reference is
not None:
+ # when copying 'Person' objects 'Person_afterClone' scriptis
+ # called which will reset to None reference propeprty but it
will
+ # loose username which is not acceptable thus restore it.
+ obj.setReference(default_reference)
+ obj.wl_clearLocks()
# if portal types upgrade, set backup properties

[Yoshinori Okuji]

Post by Ivan Tyagov
When a 'Person' object is contained inside a business template file and
this Person object has set an username ('reference' property) after
installing this bt5 file this properly is set to 'None' and thus it's
not a valid ERP5 user. What happens is that in business template
installation 'manage_afterClone()' is applied to every installed object
including 'Person' which is fine.
But the default behavior for 'Person' is to reset reference in
'Person_afteClone()'.
Because manage_afterClone() --> Person_afterClone() chain is normally
called when a Person object is copied/pasted and by exception when a
business template is installed I would like to introduce this patch that
will restore 'reference' when a 'Person' objects is installed from bt5
file.
Any ideas how this can be done in a more elegant way/place are welcome.

We need a generic solution. It is unmaintainable to work around for every
specific case.

The first question is whether it is required to call manager_afterClone for an
object copied from a business template. I guess this is not necessary. If I
am correct, you can simply remove the calling. But I may be wrong.

If you cannot remove it, we need a way to bypass reseting properties (i.e. not
to call a script specified by a portal type), by passing a parameter to the
method, for example.

YO

[Jérôme Perrin]

Post by Yoshinori Okuji
The first question is whether it is required to call manager_afterClone for
an object copied from a business template. I guess this is not necessary.
If I am correct, you can simply remove the calling. But I may be wrong.

Maybe we only need to call reindexObject.

Post by Yoshinori Okuji
If you cannot remove it, we need a way to bypass reseting properties (i.e.
not to call a script specified by a portal type), by passing a parameter to
the method, for example.

manage_afterClone on objects created by business template is a general
problem, because it will delete workflow_history attribute, thus reset all
workflow states for the object.

J?rome

[Ivan Tyagov]

Post by Jérôme Perrin

Post by Yoshinori Okuji
The first question is whether it is required to call manager_afterClone for
an object copied from a business template. I guess this is not necessary.
If I am correct, you can simply remove the calling. But I may be wrong.

Maybe we only need to call reindexObject.

We can not safely remove 'manage_afterClone()'. This can have a lot of
unexpected behavior for different portal types.
'reindexObject()' anyway will be called (at least that I observed) for
every object installed from bt file.

Post by Jérôme Perrin

Post by Yoshinori Okuji
If you cannot remove it, we need a way to bypass reseting properties (i.e.
not to call a script specified by a portal type), by passing a parameter to
the method, for example.

manage_afterClone on objects created by business template is a general
problem, because it will delete workflow_history attribute, thus reset all
workflow states for the object.

That's correct and it's one of the reasons I think we shouldn't remove
the call to it.

The main problem in finding a general solution is that there's a
difference between creating an object from scratch (i.e. using UI or by
script) and creating an object out of a business template. This
difference becomes apparent for mentioned use-case ('Person' object).
And unfortunately 'manage_afterClone()' is not aware of that fact.
One way is to pass another generic argument to it indicating that we're
installing the object out of a template. This argument will be passed to
the responsible portal_type script which for Person is
'Person_afterClone' and in this method we can implement specific logic.

Ivan

[Ivan Tyagov]

Post by Yoshinori Okuji
We need a generic solution. It is unmaintainable to work around for every
specific case.
The first question is whether it is required to call manager_afterClone for an

It's required.

Post by Yoshinori Okuji
If you cannot remove it, we need a way to bypass reseting properties (i.e. not
to call a script specified by a portal type), by passing a parameter to the
method, for example.

I would like to propose that we extend the arguments passed to scripts
like '<PortalType>_afteClone'. Currently this scripts doesn't accept any
arguments at all and thus we can not implement any logic for reseting or
not properties inside them.
Implementing this logic inside 'manage_afterClone' based on portal type
is not very flexible.

My suggestion is that we pass to these scripts an argument called
'pseudo_context'.
When creating an object from a business template this pseudo_context
will be the portal_templates tool itself. In any other cases
pseudo_context will be the copied object itself (which is the default
behavior).
Having this argument we can implement property reseting logic for every
type in '<PortalType>_afteClone' script.
Currently the following scripts shall be modified (just add
'pseudo_context' to parameter list):

- Person_afteClone

- AccountingTransaction_afterClone

- Invoice_afterClone


This would require following file system patches:

Index: BusinessTemplate.py
===================================================================
--- BusinessTemplate.py (revision 11986)
+++ BusinessTemplate.py (working copy)
@@ -646,7 +646,7 @@
obj = obj._getCopy(container)
container._setObject(object_id, obj)
obj = container._getOb(object_id)
- obj.manage_afterClone(obj)
+ obj.manage_afterClone(portal.portal_templates)
obj.wl_clearLocks()
# if portal types upgrade, set backup properties


Index: CopySupport.py
===================================================================
--- CopySupport.py (revision 11986)
+++ CopySupport.py (working copy)
@@ -247,7 +247,7 @@
# Call a type based method to reset so properties if necessary
script = self._getTypeBasedMethod('afterClone')
if script is not None and callable(script):
- script()
+ script(item)

# Clear the workflow history
# XXX This need to be tested again


This problem is referenced "here": http://10.8.0.78/nexedi/bug_module/561

Ivan