[Erp5-dev] RFC: Planning to rename Image and File portal types in erp5_core / erp5_base

[Jean-Paul Smets]

Hi,

I am planning to rename 2 portal types: Image and File.

Since those two types are used in all ERP5 sites, I am requesting here
for comments. I will describe the reasons and the approach which I am
considering to prevent any incompatibilities or heavy migrations.

Reasons:
- in erp5_core and erp5_base, Image and File in erp5_base are used
as a kind of property to certain objects (ex. Person, Organisation).
They acquire their local roles and do not really need a workflow.
- with the introduction of erp5_dms, Image and File have become real
documents with their specific module, complex local roles and
publication workflow. A state called "embedded" was introduced to
provide compatibility of security settings for previous Image and File data
- the property "acquire local role" is set to False in most
documents, except Image and File, which creates various troubles (ie.
the security of image_module in erp5_dms makes all images visible)
- with the introdcution of erp5_dms, populateContent method now
creates embedded HTML inside OOoDocuments which are converted to HTML.
Their "acquire_local_role" property is set to True which also creates
various troubles whenever a Web Page is embedded inside an OOoDocument
as the result of a conversion
- searches return many Image and Web Page documents which are
actually just converted items and which are not relevant
- various obvious methods (ex. interaction workflows to copy local
roles, use translation tricks) are too much a hack

Solution 1:
- rename Image to Embedded Image (acquire local roles = true)
- rename File to Embedded File (acquire local roles = false)
- include both Image, File, Embedded Image and Embedded File in
erp5_core
- remove Image and File from allowed content types in erp5_core and
erp5_base and replace them with their embedded counterpart
- add Embedded Image and Embedded File in all listbox definitions of
erp5_base which display images
- add a transparent migration method to Image and File classes. For
example, the getPortalType method could be overloaded so that, in
combination with a version checking of the Image / File instance, a
script is invoked to provide the new value of the portal_type attribute
based on various conditions (is the state embedded). Reindexing the site
or doing edit on any Image / File would be sufficient to migrate all
existing Image / File and would not cost much later.
- remove all transitions to the embedded state in publication
workflow (and remove the embedded state some day)

Solution 2:
- add __bobo_traverse__ to OOoDocument and store converted data
(HTML, images) in a separate location

Both solutions could be combined.

Comments are welcome. The idea to reduce the migration cost to zero
effort if possible. So, if the 2 solutions here can create extra work
for you, please let me know how and why.

Regards,

JPS.

[Rafael Monnerat]

Just one note,

I think one bt5 should be create to keep the compatibility for old sites
that wants to keep the old behaviour. In many cases are not interesting
this kind of migration in a short time. I'm not sure if it is easy or
not but it will be used until people decides to migrate it for the new
implementation.


Rafael Monnerat

Post by Jean-Paul Smets
Hi,
I am planning to rename 2 portal types: Image and File.
Since those two types are used in all ERP5 sites, I am requesting here
for comments. I will describe the reasons and the approach which I am
considering to prevent any incompatibilities or heavy migrations.
- in erp5_core and erp5_base, Image and File in erp5_base are used
as a kind of property to certain objects (ex. Person, Organisation).
They acquire their local roles and do not really need a workflow.
- with the introduction of erp5_dms, Image and File have become real
documents with their specific module, complex local roles and
publication workflow. A state called "embedded" was introduced to
provide compatibility of security settings for previous Image and File data
- the property "acquire local role" is set to False in most
documents, except Image and File, which creates various troubles (ie.
the security of image_module in erp5_dms makes all images visible)
- with the introdcution of erp5_dms, populateContent method now
creates embedded HTML inside OOoDocuments which are converted to HTML.
Their "acquire_local_role" property is set to True which also creates
various troubles whenever a Web Page is embedded inside an OOoDocument
as the result of a conversion
- searches return many Image and Web Page documents which are
actually just converted items and which are not relevant
- various obvious methods (ex. interaction workflows to copy local
roles, use translation tricks) are too much a hack
- rename Image to Embedded Image (acquire local roles = true)
- rename File to Embedded File (acquire local roles = false)
- include both Image, File, Embedded Image and Embedded File in
erp5_core
- remove Image and File from allowed content types in erp5_core and
erp5_base and replace them with their embedded counterpart
- add Embedded Image and Embedded File in all listbox definitions of
erp5_base which display images
- add a transparent migration method to Image and File classes. For
example, the getPortalType method could be overloaded so that, in
combination with a version checking of the Image / File instance, a
script is invoked to provide the new value of the portal_type attribute
based on various conditions (is the state embedded). Reindexing the site
or doing edit on any Image / File would be sufficient to migrate all
existing Image / File and would not cost much later.
- remove all transitions to the embedded state in publication
workflow (and remove the embedded state some day)
- add __bobo_traverse__ to OOoDocument and store converted data
(HTML, images) in a separate location
Both solutions could be combined.
Comments are welcome. The idea to reduce the migration cost to zero
effort if possible. So, if the 2 solutions here can create extra work
for you, please let me know how and why.
Regards,
JPS.

[Jérome Perrin]

Post by Jean-Paul Smets
Hi,
I am planning to rename 2 portal types: Image and File.
Since those two types are used in all ERP5 sites, I am requesting here
for comments. I will describe the reasons and the approach which I am
considering to prevent any incompatibilities or heavy migrations.
- in erp5_core and erp5_base, Image and File in erp5_base are used
as a kind of property to certain objects (ex. Person, Organisation).
They acquire their local roles and do not really need a workflow.
- with the introduction of erp5_dms, Image and File have become real
documents with their specific module, complex local roles and
publication workflow. A state called "embedded" was introduced to
provide compatibility of security settings for previous Image and File data
- the property "acquire local role" is set to False in most
documents, except Image and File, which creates various troubles (ie.
the security of image_module in erp5_dms makes all images visible)
- with the introdcution of erp5_dms, populateContent method now
creates embedded HTML inside OOoDocuments which are converted to HTML.
Their "acquire_local_role" property is set to True which also creates
various troubles whenever a Web Page is embedded inside an OOoDocument
as the result of a conversion
- searches return many Image and Web Page documents which are
actually just converted items and which are not relevant
- various obvious methods (ex. interaction workflows to copy local
roles, use translation tricks) are too much a hack
- rename Image to Embedded Image (acquire local roles = true)
- rename File to Embedded File (acquire local roles = false)
- include both Image, File, Embedded Image and Embedded File in
erp5_core

Hi,
Shouldn't Image and File be in erp5_dms ? or is it for compatibility ?

Post by Jean-Paul Smets
- remove Image and File from allowed content types in erp5_core and
erp5_base and replace them with their embedded counterpart
- add Embedded Image and Embedded File in all listbox definitions of
erp5_base which display images
- add a transparent migration method to Image and File classes. For
example, the getPortalType method could be overloaded so that, in
combination with a version checking of the Image / File instance, a
script is invoked to provide the new value of the portal_type attribute
based on various conditions (is the state embedded). Reindexing the site
or doing edit on any Image / File would be sufficient to migrate all
existing Image / File and would not cost much later.

Only for files outside document_module ? ie. how to distinguish a File
that should remain a File from a File that should become an Embedded File ?

J?rome

Post by Jean-Paul Smets
- remove all transitions to the embedded state in publication
workflow (and remove the embedded state some day)
- add __bobo_traverse__ to OOoDocument and store converted data
(HTML, images) in a separate location
Both solutions could be combined.
Comments are welcome. The idea to reduce the migration cost to zero
effort if possible. So, if the 2 solutions here can create extra work
for you, please let me know how and why.
Regards,
JPS.