*: 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>
In cases where the progress record does not yet exist, it is not
possible to toggle the visibility of the onboarding panel.
Therefore, we hide said button.
Task-3192327
closesodoo/odoo#115727
X-original-commit: 68e3e2b93d9028d6c469c627ef6d1b3c661a70a2
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>
Steps to reproduce:
- install Calendar and Appointments apps;
- give "Access Rights" for administration to a user;
- go to calendar app with this user.
Issue:
The user does not have access to the calendar.
Cause:
The user has no access rights for the onboarding model.
Solution:
Check that the user belongs to the "group_system" group in the onboarding model controller.
opw-3083014
closesodoo/odoo#107514
X-original-commit: fa7dc387154c65ef07af1f903fa25ca5d2e890f9
Signed-off-by: Arnaud Joset <arj@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
Xavier Luyckx (xlu)