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

[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

Jean-Paul Smets escreveu:
> 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.
>