### 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
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>
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
Florian Charlier