[Erp5-dev] optional actions

[Yoshinori Okuji]

I have implemented optional actions. You can configure optional actions in the
tab Actions in ERP5TypeInformation, and these actions are not included in
Business Templates automatically. You can add new actions to existing portal
types safely in this way.

YO

[Jean-Paul Smets]

Post by Yoshinori Okuji
I have implemented optional actions. You can configure optional actions
in the tab Actions in ERP5TypeInformation, and these actions are not
included in Business Templates automatically. You can add new actions to
existing portal types safely in this way.
YO

Very nice. What happens if I want to modifiy existing actions to change
their behaviour ? (ex. printing with a custom form layout rather than the
default printing action)

JPS.

[Yoshinori Okuji]

Post by Jean-Paul Smets
Very nice. What happens if I want to modifiy existing actions to change
their behaviour ? (ex. printing with a custom form layout rather than the
default printing action)

It is not an issue about actions, but about skins, right?

YO

[Jean-Paul Smets]

Post by Yoshinori Okuji

Post by Jean-Paul Smets
Very nice. What happens if I want to modifiy existing actions to change
their behaviour ? (ex. printing with a custom form layout rather than
the default printing action)

It is not an issue about actions, but about skins, right?

Not always. Most print actions currently call a standard script which
redirects to the current view of the portal_type and sets portal_skin=Print
to get a PDF rendering of the current form. This is achieved by:

Id: print
Action: string:${object_url}/Base_printPdf
Category: object_print

Sometimes, we would like to override this behaviour. One way would be in
this case to move the print action definition to the page template
(efficient but neither very clean nor very flexible).

Another way would be to override Base_printPdf so that the default print
behaviour can be overriden by an optional action (with a Category such as
"object_default_print" instead of "object_print")

Another issue is that sometimes, we want to change the permission or
condition of actions to customise ERP5 for a given customer.

I like optional actions (it is simple and efficient) but I am not sure it
solves the upgrade issue for actions which have been overriden for a given
customer site.

JPS.

Post by Yoshinori Okuji
YO

[Yoshinori Okuji]

Post by Jean-Paul Smets
Not always. Most print actions currently call a standard script which
redirects to the current view of the portal_type and sets portal_skin=Print
Id: print
Action: string:${object_url}/Base_printPdf
Category: object_print
Sometimes, we would like to override this behaviour. One way would be in
this case to move the print action definition to the page template
(efficient but neither very clean nor very flexible).

If you want to override the original, you must make a new portal type or a new
layer. There is no other clean solution.

But usually you just modify existing actions manually and that's it. When you
upgrade business templates, you need to take care of merging changes. This is
not funny, but not difficult at all. Simply time-consuming.

Actually, the idea of layers do not solve all the problem in upgrade. It
solves only the problem of "getting rid of customization". It does not solve
the problem of how to merge important changes.

Post by Jean-Paul Smets
I like optional actions (it is simple and efficient) but I am not sure it
solves the upgrade issue for actions which have been overriden for a given
customer site.

Of course, it does not solve such a complex issue, you know. My change was
required urgently to make good accounting templates, since each localized
accounting template wants to add new actions.

YO