[5.0 & 6.0] Print workflow doesn't work if there is more than one workflow defined

Bug #652213 reported by Borja López Soilán (NeoPolus)
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Server (MOVED TO GITHUB)
Status tracked in Trunk
6.0
Fix Released
Undecided
OpenERP Publisher's Warranty Team
Trunk
Incomplete
Low
OpenERP's Framework R&D

Bug Description

The print workflow report (bin/addons/base/ir/workflow/print_instance.py) will print a blank page for objects with more than one workflow defined.

This usually won't happen for a default installation of OpenERP, as most objects currently have just one workflow. But it may happen when a developer wants to create an alternative workflow (either to replace a default workflow [the new workflow would have on_create = True, and the original workflow would be set to on_create = False], or just to have alternative workflows that would be instanced by hand [on create = False]).

*** HOW TO REPRODUCE ***

- Print the sale order's workflow => it works.
- Go to Administration -> Customization -> Workflow definitions -> Workflows.
- Create a new workflow (as simple as possible) for the sale order.
- Set the new workflow as default ("On Create" set), and disable the original one ("On Create" unset).
- Print the previous sale order's workflow again => it works (still uses the original workflow).
- Create a new sale order (this sale order will get the new workflow).
- Print the new sale order's workflow => it prints a blank page.

*** DETAILS ***

When generating the report, only the first kind of workflow available for the given model (for the sale order object for example) is checked. So, when the object (whose workflow instance is being printed) created ("on create") a different kind of workflow, it is unable to find the workflow instance to print and a blank page is printed instead.

*** SOLUTION ***

- The report should check first if the object has a workflow instance already and, if available, use that instance workflow instead of the default one.
- Otherwise (new object instance), the first workflow with "on_create" should be used (instead of just the first one).

Revision history for this message
Borja López Soilán (NeoPolus) (borjals) wrote :
Changed in openobject-server:
status: New → Triaged
Changed in openobject-server:
assignee: nobody → OpenERP's Framework R&D (openerp-dev-framework)
importance: Undecided → Low
status: Triaged → Confirmed
Revision history for this message
Naresh(OpenERP) (nch-openerp) wrote :

for trunk version its working fine...the new work flow is taken into account while printing it..
So I am closing it for the trunk series and assigning it to the 6.0 where its reproducible here it prints blank page as mentioned in the original bug description.

Thanks,

Revision history for this message
mvhman (michael-openrevolution) wrote : Re: [Bug 652213] Re: [5.0 & 6.0] Print workflow doesn't work if there is more than one workflow defined
Download full text (3.4 KiB)

Hi Naresh,
Why did you send me this bug status.
I think you have sent it to the wrong person.
I have a printing problem but I have not adjusted the workflow in our
company.
My ticket reference is: [5961]

regards,
Michael

On Mon, May 30, 2011 at 3:12 PM, Naresh(OpenERP) <email address hidden> wrote:

> for trunk version its working fine...the new work flow is taken into
> account while printing it..
> So I am closing it for the trunk series and assigning it to the 6.0 where
> its reproducible here it prints blank page as mentioned in the original bug
> description.
>
>
> Thanks,
>
> ** Also affects: openobject-server/6.0
> Importance: Undecided
> Status: New
>
> ** Also affects: openobject-server/trunk
> Importance: Low
> Assignee: OpenERP's Framework R&D (openerp-dev-framework)
> Status: Confirmed
>
> ** Changed in: openobject-server/6.0
> Status: New => Incomplete
>
> ** Changed in: openobject-server/6.0
> Status: Incomplete => Confirmed
>
> ** Changed in: openobject-server/trunk
> Status: Confirmed => Incomplete
>
> ** Changed in: openobject-server/6.0
> Assignee: (unassigned) => OpenERP Publisher's Warranty Team
> (openerp-opw)
>
> --
> You received this bug notification because you are subscribed to 6.0.
> https://bugs.launchpad.net/bugs/652213
>
> Title:
> [5.0 & 6.0] Print workflow doesn't work if there is more than one
> workflow defined
>
> Status in OpenERP Server:
> Incomplete
> Status in OpenERP Server 6.0 series:
> Confirmed
> Status in OpenERP Server trunk series:
> Incomplete
>
> Bug description:
> The print workflow report
> (bin/addons/base/ir/workflow/print_instance.py) will print a blank
> page for objects with more than one workflow defined.
>
> This usually won't happen for a default installation of OpenERP, as
> most objects currently have just one workflow. But it may happen when
> a developer wants to create an alternative workflow (either to replace
> a default workflow [the new workflow would have on_create = True, and
> the original workflow would be set to on_create = False], or just to
> have alternative workflows that would be instanced by hand [on create
> = False]).
>
> *** HOW TO REPRODUCE ***
>
> - Print the sale order's workflow => it works.
> - Go to Administration -> Customization -> Workflow definitions ->
> Workflows.
> - Create a new workflow (as simple as possible) for the sale order.
> - Set the new workflow as default ("On Create" set), and disable the
> original one ("On Create" unset).
> - Print the previous sale order's workflow again => it works (still uses
> the original workflow).
> - Create a new sale order (this sale order will get the new workflow).
> - Print the new sale order's workflow => it prints a blank page.
>
> *** DETAILS ***
>
> When generating the report, only the first kind of workflow available
> for the given model (for the sale order object for example) is
> checked. So, when the object (whose workflow instance is being
> printed) created ("on create") a different kind of workflow, it is
> unable to find the workflow instance to print and a blank page is
> printed instead.
>
> *** SOLUTION ***
>
> - The rep...

Read more...

Revision history for this message
Ravi Gohil (OpenERP) (rgo-openerp) wrote :

Hello Borja,

   The issue is not being generated for stable v6 now. Can you please check it at your end with the latest revision i.e. 3450 ?

I am closing the bug for now. Kindly do notify us if it still persists.

Thanks.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.