In 8e3283aa we solved the issue of onboarding progress records
preventing the deletion of a company. We also added a test for this
solution.
In practice, it will not always make sense nor will it be allowed to
delete a company and in some cases, the first thing that would fail
is a foreign key from another model where it wouldn't make sense to
cascade as we do for onboarding progress.
Some modules create related records when a company is created such
that it would be cumbersome to bypass that.
Therefore, we disable this test until a clean flow robust to all
sorts of installed modules configuration is implemented.
See runbot 60475
Task-3829936
closesodoo/odoo#159679
X-original-commit: ea215fe59b45a0c4ff29b4defb38f9ae91a6ca37
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
When onboarding was updated to override web assets in 518a4e4c43 it should also have been updated to *depend* on web.
closesodoo/odoo#141474
X-original-commit: 76907e3b34d8e33943024772e373fd0c3228b1f8
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In many situations, when you click on a button, you want to disable all
the other buttons while it is running.
Currently, in each of these situations, we duplicate the same code that
disabled all the buttons and enabled them afterwards. Unfortunately, in
many cases, if the code executed crashes, the buttons are not enabled.
In this commit, we're going to create a helper so that we have a single
version of the code that correctly handles crashes. This helper will
disabled all the buttons, then execute the click code and enabled all the
buttons afterwards. If the code crashes, it will also enbaled them.
The problem has been reported for the Settings Form view:
When you edit this view and click save, if an error occurs in the save,
all the buttons remain disabled.
closesodoo/odoo#140938
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit introduces some adjustments to the dark mode color scheme
and the use of bootstrap classes in Community.
- Mini calendar contrast -
The colors were not using variables, making them non dynamic
and breaking the contrast in dark mode.
- Avoid !important rules spreadsheet -
Prior to this commit, spreadsheet top bar was using a `bg-white` class,
making it pure black in dark mode.
Since spreadsheet is designed with light colors and we don't provide a
dark mode for it, we remove that class and set a `background-color`
property using CSS in Enterprise.
- Input color -
This commit fixes the focus behavior on the searchbar in the control
panel, the `command_palette_search`, and the `start a conversation` in
discuss.
- Copy clipboard field border color -
Make use of the `text-primary` color for the copy to clipboard field
We use the o-theme-color function to avoid an undefined since primary
doesn't exist in the o-theme-text-color map in white mode.
- Web_editor toolbar variables -
The toolbar was using the `o-brand-primary` variable
which was set to a darker shade. This caused issue when activating an
option due to how vibrant the color is.
- Improve the controls on border-color -
Introducing a custom property on the border-color to allow
further control on individual components (such as the popover).
- Improve setting tabs colors use -
Prior to this commit, the colors of the settings tabs menu were kinda
inverted. The menu was light in dark mode and dark in light mode.
We fix this by changing the values associated to the CSS variables in
use.
- Make model field selector dark mode proof -
Fixing the design of the model field selector popover in both
light and dark mode. Since the popover was using custom style with
arbitrary values, it was not designed for the dark mode and had a lack
of consistency.
To improve the design, we use variables rather than custom style, and
make sure the desired render is as close as before.
- Sign colors use -
This commit aims to improve the sign module in both light and dark mode.
There were some readability issue with some `btn-light` having poor
contrasts in both light and dark mode, and the use of some classes was a
bit unexpected (e.g `card-header` to set a grey background with some
padding).
- Improve buttons design inside listview -
Prior to this commit, this button was using custom CSS to make it look
like a primary button, while it was using classes related to secondary
buttons.
We remove the custom CSS used to style it correctly and keep our button
design consistent.
- Messaging menu layout in mail -
This commit aims to improve the design of the notifications displayed
in the messaging menu. Prior to this commit, the notifications dropdown
was using custom CSS variables overriding the regular behavior
of our dropdowns.
In fact, the layout was generating some friction:
1) Marking a notification as read would turn its background into a
darker color
2) Effects like `:hover` were all based on the custom CSS variables
resulting in an inconsistent layout.
- Multi company selector adaptations -
In darkmode the multi company selection was using the btn-light which
creates a weird effect and overrides the dropdown default hover behavior
This commit uses the btn-link to display an hover effect on the
company switch and on the checkbox while blending with the background
and the default dropdown hover effect.
- Adapts default badge design -
Improve the design of the default badges in dark mode.
If you open the light mode, these badges are dark grey with a white
text. If you switch to dark mode, they are dark grey but with a dark
text, which makes them look either muted or off.
We make use of SCSS variables to handle the color of the component,
providing a good styling in both modes.
- Fix kanban cards borders inside dropdown -
Fixes the issue with the divider inside the kanban dropdown menu not
showing in dark mode.
To ensure it is visible, we assign it the `$dropdown-divider-bg`, which
is the color it should use, as the horizontal divider above uses.
- Fix tour pointer design for dark mode -
This commit aims to insert the tour pointer and its content inside the
styling we applied to our tooltip.
To do so, we make sure it uses CSS variables, allowing more control and
consistency, plus we replicate the overall look of our tooltips.
- Fix `text-primary` on action background contrast -
This commit improves the readability of our `text-primary` classes when
it's used on a `$o-component-active-bg` background.
Prior to this commit, the `text-primary` was not meeting the contrast
standard, mainly when you were using the `CMD+K` shortcut on the
app switcher.
To prevent that, we changed the background to a `$o-component-active-bg`
background with an opacity ensuring our text provides a good contrast.
- Fix input states -
Prior to this commit, the `--o-input-border-color` CSS variable was
using the `$o-form-lightsecondary` variable to define the standard color
of the `border-bottom` property of our inputs.
This was conflicting since `$o-form-light-secondary` is also used to
define the `background-color` of our table on focus.
With this commit, we separate these two element with different variables
to make sure they don't affect each others.
- Fix kanban ghost background -
Before this commit, if you created a project without any stage or element
in it, the ghost cards that act like placeholders would be pure `#000` in
dark mode, due to the `bg-white` class.
This commit replaces that class with a `bg-light`, providing a better
visual result in both light and dark mode.
- Fix new message design -
Improve the design of the new message element while
inside Discuss, using our danger color, ensuring a good visual result in
both modes.
task-3201038
closesodoo/odoo#139966
Related: odoo/enterprise#49666
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Co-authored-by: chgo-odoo <chgo@odoo.com>
Co-authored-by: stefanorigano <sri@odoo.com>
This commit fixes an issue about the `onboarding.variables.dark.scss`
file not being taken into account inside the manifest.
Since saas-16.4, there is an issue with the onboarding files.
If you turn on the dark mode, the `.variables.dark` overrides are not
taken into account, but instead display the light mode variables.
This causes readability issue about the text being too dark.
This seems to happen because the dark mode file is already loaded
with the light one.
task-3201038
closesodoo/odoo#140090
X-original-commit: 9e1e72bfff1a8f27513dbb2a2a2aae0213bc78ed
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Chrysanthe Gomrée (chgo) <chgo@odoo.com>
Maintain the playful tone whilst avoiding nonsensical phrasing.
I will not take comment at this time, thank you.
Task-🤔🙃😬💅😐🤓closesodoo/odoo#138302
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Before this commit error messages in odoo are boring and
not much attractive to user. Those were like odoo is preventing
them from doing something user want to do.
In this commit, we have modified the message to be a more friendly
and humorous tone, making it less tedious and more enjoyable. It
aims to enhance the user experience and ensure that interactions
with any application are both pleasant and informative. As a result,
the messages have been clear, short, easy to understand and informative.
task-3356114
Part-of: odoo/odoo#124820
Co-authored-by: Kamlesh Pathekar <kpt@odoo.com>
Reproduce:
1. Open "Sales" app.
2. Open the fist step about company data
3. Hit "Save"
4. The step should have been marked as complete
onboarding: Since the relational model refactoring,
saving a record that is not changed will not result in
calling the onRecordSaved callback, while saved will be `true`
in `saveButtonClicked`.
web: Be more explicit about this fact in the onRecordSaved doc.
Task-3516270
closesodoo/odoo#136143
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit removes the usage of Bootstrap's Collapse widget and replace
it by the `useTransition` hook when discarding an OnboardingBanner.
task-3439226
closesodoo/odoo#133917
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Issue: the onboarding background is too dark and the view could breath
more on large screens
Fix: Use a slight linear gradient to reduce the darkness feeling and
add responsive spacing
task-3378939
part of: task-3326263
closesodoo/odoo#127152
X-original-commit: bcffa4145b9fcc7200784088f858ff4147a00e49
Signed-off-by: Pierre Paridans (app) <app@odoo.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
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>
Odoo Translation Bot