PURPOSE
Settings allow to change colors used in emails (primary and secondary colors). Those are used for headers and buttons. They are currently shared with colors used for documents and reporting: changing email colors change documents colors, which is not expected nor clearly indicated.
SPECIFICATIONS
Split configuration: colors used in documents may differ from colors used in emails. Duplicate color fields (primary and secondary). To ease setup when updating documents colors, update mail colors accordingly. Inverse is not true as we consider documents being the main configuration, and emails a more fine-grain configuration.
Task-3346388
closesodoo/odoo#123678
Related: odoo/upgrade#4735
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
PURPOSE
Settings allow to change colors used in emails (primary and secondary colors).
Those are used for headers and buttons. They are currently shared with colors
used for base documents and reports layout: changing email colors change
documents colors, which is not expected nor clearly indicated.
SPECIFICATIONS
Split configuration: colors used in documents may differ from colors used in
emails. Duplicate color fields (primary and secondary). To ease setup when
updating documents colors, update mail colors accordingly. Inverse is not
true as we consider documents being the main configuration, and emails a
more fine-grain configuration.
Task-3346388
Part-of: odoo/odoo#123678
Purpose of this commit is to regroup some tests, or rename some too specific
files in order to avoid explosion of files, making tests hard to find when
looking for feature-specific tests.
Task-3346388
Part-of: odoo/odoo#123678
The website frontend apps menu list is not working when the user has a
`Home Action` defined on his user.
The `Home Action` is meant to redirect to the defined action whenever
that user is login in.
But since the backend menu links on the website have most of the time
no `action` defined but just a `menu_id` defined, the `Home Action` will
kick in and take over the redirection, the same way as if the user just
type `/web` without any params.
To solve that, we simply force the `action` of those links (if they
don't already have one).
This will make sure that the redirect is working as it should for users
having a `Home Action` set.
Step to reproduce:
- Set a Home Action for any user, like "Contacts"
- Go to the website frontend, eg on `/`.
- Click on the top left button to show the backend app menus list
- Click on any menu (CRM, Invoicing, Calendar..)
-> Most of those menu will not redirect you were you are supposed to be
but on your Home Action instead.
You can figure which one will be buggy or not by just mouseovering
the link and see if the URL param `action` is set to something or
not.
--- Technical hints ---
There is multiple methods to get the list of menus in Odoo:
- `load_web_menus`: called by the web client rpc, calling `load_menus`.
If a top/app menu has no action defined on it, it sets the first found
action of their children menus to it.
It returns the full (flat) list of menus, not only the top/app ones.
This method is not ormcached but is calling an ormcached method and
just doing some tiny work on the data.
- `load_menus_root`: called only by website backend template to add the
app list on the website (in the frontend) to jump to the backend.
It does not force the action if a menu has no action set on it.
It returns only the top/app menus.
This method is ormcached.
Note that this method seems only used by the website module.
- `load_menus`: returns the full (flat) list of menus without a force
action
This method is ormcached.
Fixes https://github.com/odoo/odoo/issues/119971
task-3378963
closesodoo/odoo#127840
X-original-commit: f28a349aa40b2ea48ef8f2b71e806b965777014f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Backport of `_get_guest_from_context`.
Prevent crash when unexpected (not recordset) values are in the context.
Ensure the mere existence of a value (example integer) does not lead to
executing flows where an actual guest is expected.
task-2819597
closesodoo/odoo#127831
X-original-commit: 3d1890e88b99f059377d8b227b56d77798157397
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Prior to this commit, the translate button was in uppercase.
To maintain consistency with other buttons, this commit changes the
button to lowercase.
task-3414983
Part of task-3326263
closesodoo/odoo#127828
X-original-commit: 52f0bf2f2581b77a32d5e92fe1ae03d9787db5b4
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit reduces the vertical padding of `.o_kanban_header` to
display more kanban cards at a time in the view vertically
part of task-3326263
closesodoo/odoo#127827
X-original-commit: dc5f4f7cef67b256eb50cb15e1ae1f22aa124966
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
When converting a row with items that are supposed to be stretch-aligned
we need to set each of its column's height. However this failed when
the row contained less than two columns.
opw-3371134
closesodoo/odoo#127813
X-original-commit: 7df4cc0d9aaccf0dabcc4a7863549b276efaa403
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If user tries to publish or unpublish the forum post from forum posts list view,
a traceback will appear.
Steps to reproduce the issue:
- Install website_forum
- Configure website
- Go to Website -> site -> Forum Posts
- Select any post -> Action -> 'Publish' or 'Unpublish'
Error: A traceback appears:
"ValueError: Invalid field 'is_published' on model 'forum.post'"
https://github.com/odoo/odoo/blob/551685368971161975d64f480e9bec326db8931e/
addons/website/static/src/components/views/page_list.js#L69
Here we will receive 'forum.post' in this.props.resModel.
is_published field is not present in the 'forum.post' model,
So it will lead to above traceback.
sentry-4256037237
closesodoo/odoo#127476
X-original-commit: 16943c482c9ba8e12eab697ceb48a3ef6ee6c2fb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Renilkumar Kajavadra (reka) <reka@odoo.com>
In the translation PR (#111044), we translated the tax group and
invoice label but for the invoice label we didn't added to translation it needed
to have. This commit fix that.
closesodoo/odoo#125017
Task: 3369579
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
In the translation PR (odoo#115968), we translated the tax group and
invoice label but for the invoice label we didn't added to translation it needed
to have. This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (odoo#108954), we translated the tax group and
invoice label but for the invoice label we didn't added to translation it needed
to have. This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (odoo#109494), we translated the tax group and
invoice label but for the invoice label we didn't added to translation it needed
to have. This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (odoo#110661), we translated the tax group and
invoice label but for the invoice label we didn't added to translation it needed
to have. This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (odoo#110938), we translated the tax group and
invoice label but for the invoice label we didn't added to translation it needed
to have. This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (odoo#109147), we translated the tax group and
invoice label but for the invoice label we didn't added to translation it needed
to have. This commit fix that.
Also in this commit i've redone the taxonomy that has been overwritten by another
PR.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (odoo#110986), we translated the tax group and
invoice label but for the invoice label we didn't added to translation it needed
to have. This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (odoo#112160), we translated the tax group and
invoice label but for the invoice label we didn't added to translation it needed
to have. This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (odoo#111656), we translated the tax group and
invoice label but for the invoice label we didn't added to translation it needed
to have. This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (#110930), we translated the tax group and
invoice label but for the invoice label we didn't added to translation it needed
to have. This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (odoo#106324), we translated the tax group and
invoice label but for the invoice label we didn't added to translation it needed
to have. This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (odoo#106324), we translated the tax group and
invoice label but for the invoice label we didn't added to translation it needed
to have. This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (odoo#109504), we translated the tax group and invoice
label
but for the invoice label we didn't added to translation it needed to have.
This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (odoo#111107), we translated the tax group and invoice
label
but for the invoice label we didn't added to translation it needed to have.
This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (#110656), we translated the tax group and invoice label
but for the invoice label we didn't added to translation it needed to have.
This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (odoo#108725), we translated the tax group and invoice label
but for the invoice label we didn't added to translation it needed to have.
This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (odoo/enterprise#35296), we translated the tax group and invoice label
but for the invoice label we didn't added to translation it needed to have.
This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
In the translation PR (#112803), we translated the tax group and invoice label
but for the invoice label we didn't added to translation it needed to have.
This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
Before this commit, when trying to install the l10n_sa or l10n_ae localization,
we get an error in the chart template resulting in no demo data installed. In
fact, when doing a Command.update to link the account to the journal in the
files template_sa and template_ae. The "values" dict was always filled no matter
the Command, this mistake had repercussion on the "deref" method.
In the deref method we do a loop on values items, but in the case we are facing
the last_part variable was filled with an integer.
When doing the recursion in case command is a "create" or an "update", the new
values is the last_part, so the loop on values items raised an error since we
cannot do a .items() on an integer.
closesodoo/odoo#116643
Related: odoo/upgrade#4687
Signed-off-by: John Laterre (jol) <jol@odoo.com>
In this pr, we have improved the l10n_hu localization by adding a Tax rounding
(global) by default.
Also, a lot of localization will need a delivery date on invoices. We added a
field in account that can be overridden if needed. In this pr, we did an
override on l10n_sa and l10n_hu.
When creating a sale order and that the effective date is fill, we take this
value for the delivery date.
The delivery date field will always be displayed in the other info tab, and if
there is a delivery data, the field is also display in the header of the form
view. Exception for l10n_sa and l10n_hu where the delivery date is always
present.
Also for l10n_sa company there was a problem with the vat number, it was not in
the right format.
Task-id: 3191530
Part-of: odoo/odoo#116643
This commit makes use of the useAutoFocus hook to focus the input
when the SelectMenu opens. This usage of the hook can replace the
manual focus that was applied when the dropdown opened.
The feature can hardly be tested with newer tests, since the behavior
is identical, and the focus on the input was already tested.
closesodoo/odoo#127864
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Before this commit:
- The icon of table menu is fa-bars which looks like drag 'n' drop handle.
- Menu width is not 100%.
After this commit:
- Changed the icons to fa-ellipsis-h and fa-ellipsis-v.
- Made the menu 100% width so it's easier to intuit it's not a drag 'n'
drop handle.
Task - 3297710
closesodoo/odoo#127843
X-original-commit: 479c0a87b0b676f5fa9252efdef3ede99f6d7ea7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
domain = host = hostname + port
Cause: https://github.com/odoo/odoo/pull/125251
Steps to reproduce:
- Add in the custom with a href's host different than the current database host
- Open website
- Edit it
- Click on a block OR add a block and try to save
Actual:
- Infinite loading due to SecurityError on the cssRules fields
Expected:
- No infinite loading
opw-3432734
opw-3438480
opw-3435892
opw-3371073
closesodoo/odoo#130151
X-original-commit: 8d550d5cc5f055a9de26e3b050550268710b1827
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
If you have some leads which are nearly always won or lost, you may
end with a probability which is either 0% or 100%.
These values indicate that the lead is lost or won, therefore we must
check the limit values.
opw-3413206
closesodoo/odoo#130109
X-original-commit: 49166f3c291c44d6635d30687ec8d439de145d01
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Step to Reproduce at Runbot:
-> Install Coupons & Loyalty and Contacts Apps
-> Open Contacts form view
-> AccessError telling you that you cannot read loyalty program & cards
See this video url:
https://watch.screencastify.com/v/ygI1wjVyP5xo5tWTzeST
closes odoo/odoo#130092
Part-of: #107375
X-original-commit: 4c31ef775579b6c7163c91fa2069fcc64819f940
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Let's assume a form view with several occurrences of the same
field. Each occurrence could have different modifiers values (for
readonly, required or invisible). We thus need to combine those
values, to determine if the field is globally readonly, required
or invisible (i.e. no occurrence visible). The way it was done
before this commit was wrong as it kind of assumed that the values
were boolean, whereas they can be strings representing domains to
evaluate. As a consequence, the "global" value of those modifiers
could be wrong. This commit fixes the issue by correctly combining
the domains.
Followup of odoo/odoo#114024closesodoo/odoo#130041
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
The translations on Spanish (Mexico) are more active than on Spanish
Moreover, most other countries speaking a variant of Spanish are
located in Latin America and are closer to es_MX than es.
To solve this, when installing for instance es_AR, the translations
will be loaded in the following order:
1 es
2 es_MX
3 es_AR
In case a term is translated in both es and es_MX (and not es_AR), the
later will be used
closesodoo/odoo#121415
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
On mouseup the toolbar size might change (eg. link button removed),
leading to an ill-positioned toolbar.
This commit makes sure the toolbar position is updated after going
through changes after a mouseup.
task-3347670
closesodoo/odoo#130022
X-original-commit: af52356704f990ecb3c8a7832fe3de8898026885
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Buttons in the floating toolbar are displayed depending on what is
selected. When selecting text that spans multiple blocks, the
"#create-link" button is hidden from the floating toolbar.
Before this commit, when the "#create-link" button was hidden, the
"#link" button group would be left empty but still visible on the
toolbar (its separator bar remained visible).
This commit ensures that:
- the responsability of displaying/hiding the "#unlink" button
is from Wysiwyg's _updateEditorUI method, as it is the case with the
other toolbar buttons,
- when a button group has none of its children button visible, it is
made invisible too, including its separator bar.
This commit also fixes the selector for toggling the "#create-link"
button active/inactive, bringing the affected code section alive from
the dead.
task-3347670
X-original-commit: ceedd72b893316f5994727063a6a6faf49476408
Part-of: odoo/odoo#130022
When the floating toolbar is placed at the bottom of the selected text,
an arrow should be visible above the toolbar (pointing to the selected
text).
The CSS ruleset that makes such arrow visible was not being applied due
to an error in the CSS selector.
task-3347670
X-original-commit: 1a526b915d185e0b29bd3f9a3ff67df5178450d4
Part-of: odoo/odoo#130022
Since https://github.com/odoo/odoo/pull/114024, the notification service is no longer used in the `ListController`.
However, this service is needed in the data_merge list controller.
This commit adds the service to `DataCleaningCommonListController` so that it can be used in data_merge.
closesodoo/odoo#130018
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- Open a kanban view inside the project app
- Click on the "Quick Assign icon"
- Select a user A
- Directly unselect this user
- Close the dropdown and open the edited record
- you can see the user A is still assigned => bug
This bug was occurred by a missing awaiting promise inside the deleteTag
method.
closesodoo/odoo#129996
X-original-commit: b345af5389cd0cc3eb5e373d50ea62afc4e46b22
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
Before this commit, the ace field was marked as dirty only on a blur,
this behavior is incoherent vis-à-vis the other fields that are mark as
dirty as soon as the user type something. Also, this field can be large,
and the user can work in it for a long time, and it's important for the
user to have a visual feedback (the save and discard buttons), when
modifying this field (this is already the behavior of the similar html
field).
closesodoo/odoo#129995
X-original-commit: 186013f3df78b629b997fc0acf5043b545198a9e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when using the ace field widget with a html field,
the markup value of the field was sent to the code editor. The issue
with this is that the ace library only accept strings (it will extract
the string from the markup), and when ask for the current value, it will
respond in string. Because of this, the ace field will always be
considered as dirty, even if not modified, because it will compare the
initially sent value (a markup) with the value given by the library (a
string).
Now, the formatText used on the ace field will always send a string
(remove the markup). And the code editor will check the props to only
accept strings.
X-original-commit: 1778672e9b0076bf385d46e68efb4914d6bf790c
Part-of: odoo/odoo#129995