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>
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