Steps to reproduce issue:
1. Download Accounting (or Sales or just Invoices)
2. Open Accounting
3. Create Company 2 and switch to it
4. Open Accounting again
5. Remove Company 2
6. Open Accounting
7. You receive an error:
> ValueError: Expected singleton: onboarding.progress(1, 2)
Explanation:
In `_compute_current_progress`, the filter to get `current_progress_id` accepts `onboarding.progress` with both the company in which the user is at the moment or no company at all.
https://github.com/odoo/odoo/blob/77f9ff50db3cdb88397d0b1cc7042c772d0d417b/addons/onboarding/models/onboarding_onboarding.py#L55-L69
This is due to the fact that some onboardings are not related to a company while others are.
After that, getting the `onboarding_state` will trigger an `ensure_one` check.
In the current case, an `onboarding.progress` with a `company_id` is not deleted once the company is deleted. Therefore the value becomes `False`. The `ensure_one` that comes after will throw an error because of it.
Suggested fix:
`ondelete` decorator requires the module to be upgraded. For this issue, it is preferable to have a fix that is automatically applied. The added method simulates the `cascade` effect of `ondelete` and does not require the module upgrade.
opw-3762382
closesodoo/odoo#157142
X-original-commit: 8e3283aabfd93a78eb4d72c4fd97f6a20ad08ef4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* = account{_payment}, base, onboarding, payment{_stripe},
sale{_management}, web, website_sale
Use the dedicated onboarding module introduced in 16.0 instead of
the res.company model to store onboarding progress.
It allows
* onboarding steps to be reused across panels
* to support steps that should be completed per-database or per-company
* to clean the res.company model from many fields and methods,
* to remove many views, controllers, actions
Module-specific notes:
* account: We also clean the remaining two steps that are not
part of an accounting panel but make the most sense to be kept here.
* account_payment: Following 8e4e8eb8, the payment provider step is
added to the invoicing onboarding panel. We apply this change here too.
Also impacts the website_sale_dashboard panel (see related ENT PR).
(The "sale tax" one is currently used for to the website sale dashboard).
* payment: Note that the step was already not part of an onboarding
panel within this module.
* website_sale: We clean
* a field not used (The website_sale dashboard onboarding panel used
the payment_provider_onboarding_state field).
* a method that was only called from website_sale_dashboard, so it is
moved there. See related ENT PR.
Includes a few tests.
Moving views/templates/styling, as well as cleaning residual onboarding-related fields and methods in base, including populate.
This also includes restoring the "onboarding_complete" overlay panel
animating it to disappear after a few seconds so that it doesn't hide
text and block buttons to re-open steps.
Task-3025136
Part-of: odoo/odoo#104223
### enable onboarding step sharing
Purpose: Allow to use the same step (and progress) for multiple
onboardings.
This is required for the migration of some onboardings such as the
`account` invoicing and sale `quotation` onboardings which both use
common steps (s.g., "Set up company data").
This is done by mutating the onboarding - onboarding step relation and
progress - progress step models relationships to m2m:
* Progress step records are now linked to several progress records if
the step they track is used in several onboardings.
* There will still be multiple progress step records for per-company
tracking, if applicable.
### Allow steps w/o onboarding
This commit enables creating and tracking the completion of
onboarding steps that are not included in an onboarding panel.
Before this PR, such steps could already be defined and used.
This is the case of the `payment_provider` step from the payment
module, that could be included in an onboarding panel defined
in website_sale_dashboard (both are migrated in later commits of
this PR and related ENT).
### Support changing is_per_company
Having onboarding (steps) being immutably per-company or not
per-company is not convenient. We are here taking advantage of the
migration of onboardings (next commits) to have a working framework
for these changes.
The alternative solution of having to change all onboardings and linked
steps together and ensuring all or none are per-company was in fact
more complex to support and fragile as depending on python constraints
on the many2many relationship.
We also considered it wasn't worth the complexity to identify which
onboarding_progress record could safely be removed when its last
'per-company' step is updated to not per-company.
In that case, all companies will have to close the panel independently,
but the completion of each remaining step will not have to be done for
each company.
### Miscellaneous
#### add safe close action
This eases the handling closing an onboarding panel that
may have been deleted. The code for each panel can
therefore be simplified.
#### add onboarding step form controller
Extracted from `appointment` to be reused in other modules'
onboardings.
We are also cleaning the closing behavior which is no longer
required as dialogs now do close on save/discard.
Tests are added and updated.
Task-3025136
Part-of: odoo/odoo#104223
As we prevented creating multiple records in beaae001 and cleaned the
databases for existing records in odoo/upgrade#4142, we can now safely
remove these checks.
Follow-up of Task-3101666
Task-3025136
Part-of: odoo/odoo#104223
* = account, sale
This commit allows users to modify the panel image for the
onboarding steps. This is especially necessary for additional
onboardings that can be/could have been created, or if the
appointment onboarding was modified, as it was chosen to not
overly complicate the upgrade and simply not modify these records.
We also customize the placeholder icon to be one of these icons
instead of the default "camera" image.
Finally, a few icons are renamed to be more generally usable.
closesodoo/odoo#121349
Related: odoo/enterprise#41031
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: onboarding, account, account_payment, sale.
Currently used in the appointment module (See c1cf8bfb).
Related Task-3297572
task-2818586
Part-of: odoo/odoo#116641
The purpose of this commit is to return meaningful responses when
validating steps and leave the caller to decide what to do with them.
We also introduce a public action enabling the validation of a step
from its xmlid and handle the different cases including the missing
step.
Note: these features are currently used in appointment (See Ent PR).
Additionally, returning the newly validated `onboarding_steps` from
`onboarding_step.action_set_just_done` makes more sense than returning
the `onboarding_progress_steps` records.
Tests are updated to make sure of this.
Task-3074112
closesodoo/odoo#114572
Related: odoo/enterprise#37870
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
and better handle progress requests.
In previous versions, it sometimes occurred that multiple
onboarding_progress records were created despite our measures
against that.
Two problems were identified and fixed here, together with a simple
mean to handle this error on the client-side.
1. `_sql_constraints` entry was not adequate to prevent multiple
records from being created for onboardings which are not to be
completed per-company but per database because in our version(s)
of PostgreSQL `NULL` values cannot be considered `NOT DISTINCT`,
i.e., all NULL values are different from one another so `UNIQUE`
is respected when we wouldn't want it.
Therefore, we implement here a `UNIQUE` index via the model's init,
allowing to catch unique violations when company_id is not set.
2. While we search if a record exists before creating a new one, it
could happen that another worker created a record between these
steps. As the database is configured (`REPEATABLE_READ`, which
applies until the end of the transaction, when we leave the
controller), it is very difficult to retrieve the record created by
the other process. See additional details in the testing part below.
Therefore, we chose to ask the client to perform a new request if
desirable.
Existing extra records are removed with the related UPG PR script.
### Tests
Tests are included to make sure it is not possible to create multiple
onboarding_progress records for the same onboarding and company or
without any. This includes a non-standard (runbot will not run it)
and "database breaking" (we try to clean up our mess but we cannot
give any guarantee) concurrent test that reproduce the following
scenario:
The `/onboarding/<string:route_name>` is called twice in two different
workers for a same `route_name`. The corresponding onboarding exists
and has no corresponding `onboarding.progress` record yet. Python side,
the two workers are oblivious of what's happening in the transaction of
the other worker thus any python-side-only unicity constraint would
fail to detect any progress created by other workers. This would end up
with two progress records created for a single onboarding which is
illegal.
Task-3101666
closesodoo/odoo#109221
Related: odoo/upgrade#4142
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
Multiple progress records for the same onboarding and company_id (False)
were allowed to be created in several databases which resulted in crashes.
As simple stable fix, we'll select only the latest `onboarding_progress`
records created per onboarding when trying to compute the current_progress_id
and similarly for progress steps.
This will be cleaned with an upgrade script in master so that this code should
not be necessary for long.
Task-3101666
closesodoo/odoo#109257
X-original-commit: 06f2bd985c8b98e708120226daf66b20832000bc
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
A traceback was shown when 'None' background was chosen to configure the
onboarding panel's background image (css class).
Supposing no one built anything with a `o_onboarding_False` class, we also
clean the result for a `False` value while we are here.
Task-3104723
closesodoo/odoo#108801
X-original-commit: 8a8da706e55073c48aa3cdc21201b4552230de87
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This technical module can be used to configure onboarding panels flows at
company or global level (required for new Appointment onboarding, see ENT PR).
This implementation, which should be able to support the migration of the
other onboardings, separates the closed state from the completion state
(allowing to know that steps are not completed even though the panel is
closed).
Basic tree and form view are included.
Adding an onboarding with this module requires to provide records data for the
models:
- `onboarding.onboarding` + action to close the panel
- `onboarding.onboarding.step` + actions for the 'opening' and 'saving' of each
step.
See related ENT PR for the `appointment` example, in particular
`onboarding_data.xml` and `onboarding_onboarding.py`
Several python tests are also included.
Misc. In base, we slightly refresh the wording/style of the modal closing the
onboarding panel.
Task-2852375
Part of Task-2900763
Part-of: odoo/odoo#97105
Paul Stroobant