Comment 9 for bug 514808

Revision history for this message
Borja López Soilán (NeoPolus) (borjals) wrote : Re: account - Legal Statements - General Ledger Performance issue

Ferdinand, I think that we don't just need the printjob module.
Instead of a "OpenERP is working" dialog that ends up timing out, I think we need real progress dialogs, where the user can cancel the operation and he receives some progress information.

------

By the way though not perfect, this can be actually done on the 5.0 server. And I think it could be greatly improved on the 5.2 version with a small change.

It can be done like this:

On the wizard, instead one state/activity that does the job and then shows the output (and that may time out), we might use three activities:
  - start: For starting the job in the background.
  - in_progress: For progress reporting. With a "choice" type action, that may return this state (in progress) or the next state (done).
  - done: For showing the output.

On the wizard, the start action, just spawns a second thread to do the real job and returns (we go to the in progress state).
     The spawned thread updates does the hard work and, from time to time,
     updates some 'wizard_progress' variable on the form data dictionary
     (for example on each "for loop" or each several records processed).

The in_progress state/activity, just waits for some seconds (always less than the client timeout, like 10 seconds)
      to the previously spawned thread to end, checks whether the job is done
      (wizard_progress = 100, wizard_done = True)
      or it is in progress
      (wizard_progress = XX, wizard_done = False)
      and returns "done" or "in_progress" as the next state/activity.

The user would be shown a wizard form with:
      - Some label like "OpenERP is performing X. It may be take some time."
      - A progress widget (showing the wizard_progress value).
      - Some buttons like "Continue waiting", "Perform in background" or "Cancel".
          Continue waiting will just call the in_progress activity again
          (that would wait some seconds for the job to be done, and show the same dialog again if it still in progress);
          perform in background will end the wizard, but let the thread end his job;
          and cancel would tell the child thread to stop (and rollback).

Finally when the child thread does the job, the user would be shown the results in the same way as is it done now.

As I say, this currently works, and we have done it for some wizard (take a look here: http://bazaar.launchpad.net/~openerp-spain-team/openerp-spain/5.0/annotate/head%3A/l10n_es_extras/l10n_ES_aeat_mod347/wizard/wizard_calculate.py).

And can be easily improved!: Just let the auto_refresh tag be used on the wizard forms, so the progress form can refresh from time to time without the need of the user to push the "continue waiting" button and it's done! A real progress dialog :)