Bad code in New Company Financial Setting, or more likely in every localisation module in 6

I worked out why it is different between installing a chart, and using the
server action for the second part of the report. It also call Accounting
Chart Configuration in its list of todos.

Is there any reason in local charts we can't have the same code as the
server action embedded somehow, so periods and fiscals are created as well.

On Fri, May 20, 2011 at 12:38 AM, Graeme Gellatly <<email address hidden>
> wrote:

> Public bug reported:
>
> If you look at the server action for New Company Financial Settings it
> returns all the ir.todo's that match the window action id. Now if you
> look at every single certified l10n module every single one of them in
> the installer declares an ir.todo relating to the window action id
> <field name="action_id" ref="account.action_wizard_multi_chart"/>
>
> As a result, and to test just install a few charts, and you will see you
> get multiple configuration screens of the same stuff when you run that
> action.
>
> So for me there are a couple of options - change the server action so it
> only returns the right id's somehow. Or change every l10n module so it
> doesn't create a new ir.todo and just sets the already installed one to
> open.
>
> Also worth noting, that when you install a chart directly, and click
> start configuration there is no fiscal setup, but when using the server
> action, periods and years are created.
>
> ** Affects: openobject-addons
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/785147
>
> Title:
> [stable 6.02] Bad code in New Company Financial Setting, or more
> likely in every localisation module in 6
>
> Status in OpenERP Modules (addons):
> New
>
> Bug description:
> If you look at the server action for New Company Financial Settings it
> returns all the ir.todo's that match the window action id. Now if you
> look at every single certified l10n module every single one of them in
> the installer declares an ir.todo relating to the window action id
> <field name="action_id" ref="account.action_wizard_multi_chart"/>
>
> As a result, and to test just install a few charts, and you will see
> you get multiple configuration screens of the same stuff when you run
> that action.
>
> So for me there are a couple of options - change the server action so
> it only returns the right id's somehow. Or change every l10n module
> so it doesn't create a new ir.todo and just sets the already installed
> one to open.
>
> Also worth noting, that when you install a chart directly, and click
> start configuration there is no fiscal setup, but when using the
> server action, periods and years are created.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/openobject-addons/+bug/785147/+subscribe
>

On Thursday 19 May 2011, you wrote:
> I worked out why it is different between installing a chart, and using the
> server action for the second part of the report. It also call Accounting
> Chart Configuration in its list of todos.
>
> Is there any reason in local charts we can't have the same code as the
> server action embedded somehow, so periods and fiscals are created as well.
>

FYI, I have done quite some work on that, even rewritten the account creation
engine, for the purposes of l10n_gr (copied the logic, inside
account_greek_fiscal). What you mentioned before is bugs I'd seen too when
evaluating the current wizard.
Perhaps that (in account_greek_fiscal) code will become mainstream and
completely replace the one you are referring to.

--
Say NO to spam and viruses. Stop using Microsoft Windows!

Hello Graeme,

Its fixed in lp:~openerp-dev/openobject-addons/trunk-bug-785147-ara branch. It will be merge soon with trunk addons.

Revision ID: <email address hidden>
Revision No: 4903

Thanks,
ara

merged at revision 5051 revid:<email address hidden>

Sorry, the bug is not solved yet - correcting status to indicate it is still pending while we look for the best solution to this issue (might involve changing the l10n modules as you suggested)