[Erp5-dev] [BUG?] Problem with list and button in Base_print

[Łukasz Nowak]

Hello,

Object Person has two object_print actions: one which is default
'print', second one which is custom 'custom'. Priority of 'print' is
2.0, priority of 'custom' is 1.0. Actions were reordered by 'Reorder
actions by priority'. Clicking on person object print button gives two
actions, where first one is 'custom', second one is 'print'. But submit
button 'Print' invokes Base_printPdf and 'custom' action is selected as
that one with lower priority value. Clicking on wheel reloads the page,
and now submit button configured in 'custom' action is showed. Such
behaviour is misleading to users (and it might not show in
functional/suite tests).

If there is more than one custom print action on object *AND* default
one is deleted, Base_print shows list of them, but Print button invokes
Base_printPdf; reloading page with selection other action/clicking on
wheel resloves this.

Thanks for attention,
Your human based functional tester,
Luke

PS. Of course same behaviour is observed for any type with many print
actions.

[Łukasz Nowak]

Hello,

Post by Łukasz Nowak
Hello,

I've attached patch, which in my case resolves this problem, with some
cautions:

- first action have to be form, not action, which returns print view
or
- all actions have to be forms, as its described in wiki or cps (well,
somewhere there I read about it, but I cannot remind me where it was).

And some questions:

- was my way of thinking right or wrong?
- shall all print actions registered in portal_types be forms?

Bye,
Luke
--
?ukasz Nowak R&D Ventis http://www.ventis.com.pl/
tel: [phone] int 37 fax: [phone]
https://ssl.ventis.com.pl/keys/lukasz.nowak.pub.asc
``Use the Source, Luke...''
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Folder_print.xml-actions-better.diff
Type: text/x-patch
Size: 650 bytes
Desc: not available
URL: <http://mail.tiolive.com/pipermail/erp5-dev/attachments/20061018/d4e7bc7f/attachment.bin>

[Pelletier Vincent]

Post by Łukasz Nowak
Hello,
I've attached patch, which in my case resolves this problem, with some

Thanks.
I'll have to think a bit more before integrating your patch, so don't worry if
it's not applied right away :) .

Post by Łukasz Nowak
- was my way of thinking right or wrong?

You're right.

Post by Łukasz Nowak
- shall all print actions registered in portal_types be forms?

I'm discussing about this design problem, and it's the conclusion we're at.
The idea is to provide the default action if no print action is defined on the
portal type, if there is just one print action then it must be a script (for
compatibility, anyway that script can just redirect to a form if needed), and
the other print actions - if present - must be forms.

[Łukasz Nowak]

Hello,

Post by Pelletier Vincent
Thanks.
I'll have to think a bit more before integrating your patch, so don't worry if
it's not applied right away :) .

Ok, sure.

Post by Pelletier Vincent

Post by Łukasz Nowak
- was my way of thinking right or wrong?

You're right.

Huh, what a relif.

Post by Pelletier Vincent

Post by Łukasz Nowak
- shall all print actions registered in portal_types be forms?

I'm discussing about this design problem, and it's the conclusion we're at.
The idea is to provide the default action if no print action is defined on the
portal type, if there is just one print action then it must be a script (for
compatibility, anyway that script can just redirect to a form if needed), and
the other print actions - if present - must be forms.

Well, I was thinking about it too. If default object_print action will
be script with very high priority, then after adding own object_print
actions with lower priority (and reordering forms) multiselection will work.

I wonder, if it's possibile for such script to iterate over registered
object_print actions and choose that one, which is form, not script
(well, w/o detecting scripts which redirects to forms).

Bye,
Luke