[Erp5-dev] [Erp5-report] r20588 - in /erp5/trunk/products/ERP5/bootstrap/erp5_core: SkinTemplateItem/p...

[Łukasz Nowak]

Hello,

On 2008-04-16, 15:39:16

Author: aurel
Date: Wed Apr 16 17:39:15 2008
New Revision: 20588
<dictionary>
<item>
<key> <string>_text</string> </key>
- <value>
<string>preferences/getPreferredAccountingTransactionSimulationStateList</string>
</value>
+ <value>
<string>python:here.Base_getTranslatedWorkflowStateItemList(wf_id=\'accounting_workflow\')</string>
</value> </item> </dictionary>
</pickle>

I'd like to know, if is it possible to have some kind of convention, to
not to hardcode workflow ids and similar in code?

Would it be possible to have some kind of configuration, like
'default_accounting_workflow' somewhere or fetching possible state
list based on object/portal type? I seen many commits, which was
avoiding workflow id hardcoding after some requests, but right now this
habit is coming back...

Regards,
Luke

[Aurélien Calonne]

Post by Łukasz Nowak
Hello,

Hello

Post by Łukasz Nowak
On 2008-04-16, 15:39:16

Author: aurel
Date: Wed Apr 16 17:39:15 2008
New Revision: 20588
<dictionary>
<item>
<key> <string>_text</string> </key>
- <value>
<string>preferences/getPreferredAccountingTransactionSimulationStateList<
/string> </value>
+ <value>
<string>python:here.Base_getTranslatedWorkflowStateItemList(wf_id=\'accou
nting_workflow\')</string> </value> </item> </dictionary>
</pickle>

I'd like to know, if is it possible to have some kind of convention, to
not to hardcode workflow ids and similar in code?

Sorry, it comes from a copy and paste, thanks for notifying it, I will change
it.

Post by Łukasz Nowak
Would it be possible to have some kind of configuration, like
'default_accounting_workflow' somewhere or fetching possible state
list based on object/portal type? I seen many commits, which was
avoiding workflow id hardcoding after some requests, but right now this
habit is coming back...

I think it has already been discussed on this list but no solutions has been
retained for now.
For my case I will make a library specific to order so that if you have to
change the default workflow id to use yours, you will only need to do it in
the library.

[Łukasz Nowak]

Hello,

(...)

Post by Aurélien Calonne

Post by Łukasz Nowak
Would it be possible to have some kind of configuration, like
'default_accounting_workflow' somewhere or fetching possible state
list based on object/portal type? I seen many commits, which was
avoiding workflow id hardcoding after some requests, but right now
this habit is coming back...

I think it has already been discussed on this list but no solutions
has been retained for now.
For my case I will make a library specific to order so that if you
have to change the default workflow id to use yours, you will only
need to do it in the library.

Well - it is possible to fetch workflow based possible list in context
of object associated with workflow. I was thinking about to write such
script:

def Base_getPossibleStateList(state_name='simulation_state'):
workflow = context.Base_getWorkflowForState(state_name=state_name)
return workflow.getPossibleStateList()

It might need to be proxy to manager or even use external
method. What do you think about such idea? They might use caching,
etc.

And BTW - same situation is in tests and system still.

Is it something wrong with invoking:

portal.doActionFor(object,'confirm_action')

instead (it might be found in tests, eg. testPackingList,
stepSplitAndDeferPackingList):

portal.doActionFor(object,'confirm_action',workflow_id='workflow_name')

Regards,
Luke

[Jérome Perrin]

Post by Łukasz Nowak
Hello,
(...)

Post by Aurélien Calonne

Post by Łukasz Nowak
Would it be possible to have some kind of configuration, like
'default_accounting_workflow' somewhere or fetching possible state
list based on object/portal type? I seen many commits, which was
avoiding workflow id hardcoding after some requests, but right now
this habit is coming back...

I think it has already been discussed on this list but no solutions
has been retained for now.
For my case I will make a library specific to order so that if you
have to change the default workflow id to use yours, you will only
need to do it in the library.

Well - it is possible to fetch workflow based possible list in context
of object associated with workflow. I was thinking about to write such
workflow = context.Base_getWorkflowForState(state_name=state_name)
return workflow.getPossibleStateList()
It might need to be proxy to manager or even use external
method. What do you think about such idea? They might use caching,
etc.

I also think we need such a script.
IMHO, parameters should be the state name and a list of portal types. I
made a patch. I don't know where to put this code, so for now it's a
monkey patch to WorkflowTool, that can be used like this:

python:
here.portal_workflow.getTranslatedStateTitleItemList('simulation_state',
here.getPortalAccountingTransactionTypeList())

?better idea ?

Post by Łukasz Nowak
And BTW - same situation is in tests and system still.
portal.doActionFor(object,'confirm_action')
instead (it might be found in tests, eg. testPackingList,
portal.doActionFor(object,'confirm_action',workflow_id='workflow_name')

Not as far as I know. This parameter is only usefull if you have
multiple workflows with same transition name and only want to pass one
of them.

J?rome
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WorkflowTool_getTranslatedStateTitleItemList.diff
Type: text/x-patch
Size: 1441 bytes
Desc: not available
URL: <http://mail.tiolive.com/pipermail/erp5-dev/attachments/20080519/78cc7926/attachment.bin>