Before this revision, when you pass `context` in the arguments
of a JSON routes, this one gets automatically injected
in the environment context.
This is not the case for regular HTTP routes.
It makes sense to propagate the context for the JSONRPC protocol,
JSON routes used by the backend, such as `call_kw`,
but it doesn't make sense to pass this context automatically
for any other kind of routes, such as front-end routes
or routes used by custom Javascript widgets.
This change brings a more unified behavior for routes
of types HTTP and JSON.
In addition, most developers were not aware of this "feautre",
that passing `context` in the arguments of a JSON route leaded
to the injection of this context in the environment context.
This is actually reflected by the diff size this changes required,
only a dozens of routes needed to be adapted, to manually
add the context in their route arguments and to inject it
in their environment context.
closesodoo/odoo#121726
X-original-commit: a7a5655631e6d5b05fd2ba3d0c80617aae6d9cfe
Related: odoo/enterprise#41229
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
* = 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>
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
Martin Trigaux