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
Since [1], a load_state test sometimes failed on runbot, because
we replace the legacy implementation of nextTick by the new one,
which is slightly different and sometimes a little bit faster.
In the faulty test, two nextTicks are actually required. Indeed,
changes in the url are batched in a timeout, so we must wait for
an extra tick to see the change in the DOM. This commit takes the
shot to remove/replace calls to legacyExtraNextTick in this file,
as there's no legacy layer anymore (some of them needed to be
converted into a nextTick, for the reason stated above).
[1] f40d4dc98b
Fixes runbot issue~23601
closesodoo/odoo#129980
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
*: im_livechat, website_livechat.
Before this PR, services has to be added to the setup manager in order to be loaded in tests. This was cumbersome because the setup manager was patched by each sub-feature to add feature related services to the registry. The same had to be done for systray/main components registries.
This PR automates this process in order to remove the patches.
closesodoo/odoo#129705
Related: odoo/enterprise#44596
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
This PR contains 2 commits. The first handles the bootstrap refactor and the
second refactors different views. The changes brought in the 2 commits are
described below.
**1st commit:**
Prior to this commit, the point_of_sale module relied on custom CSS.
To enhance user experience, increase flexibility, and simplify maintenance,
most of the custom css was replaced in this PR with Bootstrap utility classes.
**2nd commit**
In this commit we refactor some parts of the pos ui with the interest
of providing a simpler and cleaner codebase.
One pattern that is heavily used in the pos ui is that in which
views are changed based on the screen size at the component level.
This means that it becomes very difficult to understand what parts
of a specific template will be seen in mobile or in desktop views.
In most cases, the pos adapts for mobile screens by using the same
main components, but in different configurations. For example, a
component that was visible in desktop mode, might become accesible
through a menu in mobile mode.
In order to improve the situation, the proposed solution is to
separate the logical parts of the ui into `owl templates` and
to inject this templates wherever the need arises.
Thus, instead of constantly using `t-if="ui.isSmall"` in all places
where there is a difference between the mobile and desktop views,
we have a main conditional branch at the root level of the component
representing a certain screen and then build 2 separate views, one for
mobile and one for desktop, each calling the needed templates.
In this commit we implement this pattern for the `payment_screen`.
This will allow us to observe this pattern over a period of time,
before implementing it on the other screens.
In this commit we also:
- add small fixes and improvements relating to
the previous commit, in which the pos was
refactored to bootstrap;
- replace the `<br>` tags in the numpad component
with the bootstrap grid system;
- adapt the `cash_move_popup` to rely more on `t-model`
and less on `t-on-change`
Task: 3354582
closesodoo/odoo#129544
Related: odoo/enterprise#44197
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
pos*: point_of_sale,pos_hr,pos_loyalty,pos_restaurant,
pos_sale,
In this commit we refactor some parts of the pos ui with the interest
of providing a simpler and cleaner codebase.
One pattern that is heavily used in the pos ui is that in which
views are changed based on the screen size at the component level.
This means that it becomes very difficult to understand what parts
of a specific template will be seen in mobile or in desktop views.
In most cases, the pos adapts for mobile screens by using the same
main components, but in different configurations. For example, a
component that was visible in desktop mode, might become accesible
through a menu in mobile mode.
In order to improve the situation, the proposed solution is to
separate the logical parts of the ui into `owl templates` and
to inject this templates wherever the need arises.
Thus, instead of constantly using `t-if="ui.isSmall"` in all places
where there is a difference between the mobile and desktop views,
we have a main conditional branch at the root level of the component
representing a certain screen and then build 2 separate views, one for
mobile and one for desktop, each calling the needed templates.
In this commit we implement this pattern for the `payment_screen`.
This will allow us to observe this pattern over a period of time,
before implementing it on the other screens.
In this commit we also:
- add small fixes and improvements relating to
the previous commit, in which the pos was
refactored to bootstrap;
- replace the `<br>` tags in the numpad component
with the bootstrap grid system;
- adapt the `cash_move_popup` to rely more on `t-model`
and less on `t-on-change`
Part-of: odoo/odoo#129544
Co-authored-by: vlst <vlst@odoo.com>
Co-authored-by: Xavier Luyckx (xlu) <xlu@odoo.com>
pos*: point_of_sale,pos_discount,pos_hr,pos_loyalty,
pos_restaurant,pos_sale,pos_sale_product_configurator,pos_six
Prior to this commit, the point_of_sale module relied on custom CSS.
To enhance user experience, increase flexibility, and simplify maintenance,
most of the custom css was replaced in this PR with Bootstrap utility classes.
Task: 3354582
Authored-by: Xavier Luyckx (xlu) <xlu@odoo.com>
Part-of: odoo/odoo#129544
Co-authored-by: vlst <vlst@odoo.com>, Pedram (pebr)
In this commit 721efd0fd7e7a1fd78a812a4b752f126b455cbdb there is a typo
in a filename
opw-3341377
closesodoo/odoo#129964
X-original-commit: c4798a1e8e8aa1838a908d79d3bfacdfc6480520
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Public users do not belong to "feature" groups, so anonymous users
downloading their SO report thanks to the access_token won't ever see
the discount column as the user of the request doesn't belong to the
"Discount" group.
opw-3322583
closesodoo/odoo#129962
X-original-commit: 369d71b9fb013dc87c311da6fbad47692bfcbdaa
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When computing the category count for the ActionpadWidget, it is
possible that a product does not have one. If it doesn't, we do not take
it into account in the category count. This implementation also fixes
the crash when opening an order with a order change with a product
without category.
closesodoo/odoo#129960
X-original-commit: 86c69c2f4f91bfc91871ca0c4f6ea5acff3c975c
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
A domain condition is to compare a pos category to
the set of available pos_category ids available in pos.
This call was not working properly as the pos_categ_ids was written
pos_category_id. This led to not being able to open the pos when
the pos is category restricted. The name is now corrected.
X-original-commit: 6961d257f8885fa064e377504d807f9dc5c2a6db
Part-of: odoo/odoo#129960
Have a form view with an x2many field, and a context on that field,
depending on other fields of the view. For instance:
```xml
<form>
<field name="a"/>
<field name="b_ids" context="{'key1': a, 'key2': 4}"/>
</form>
```
As we read records in a single rpc (unity read), we need to be able
to (at least partially) evaluate the context set on b_ids to build
the field specification for the web_read call. The problem is that
the evaluation context is incomplete when we want to evalute it, as
we don't know the value of `a`.
Before this commit, we evaluated that context by adding "sentinel"
values in the evaluation context (a sentinel being a Symbol), and
we removed all keys whose values had been evaluated to the sentinel
afterwards. This worked for the example above (we were able to
generate the context `{ key2: 4 }`).
However, this wasn't flawless. For instance, with
```xml
<field name="b_ids" context="{'key1': a + b}"/>
```
our sentinel strategy didn't work, because you can't perform such
operations on a Symbol.
This commit comes with another strategy, which is actually easier,
and which handles the above case. We now parse the context, and
evaluate each value individually (if it needs to be evaluated). If
the evaluation crashes, we swallow the error and do not add that
particular key to the evaluated context.
Part of task~3179751
closesodoo/odoo#129925
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, the width of `.o_calendar_sidebar_container`was
dependent of `.o_calendar_sidebar`'s width. The problem is that the
sidebar container can contain other elements such as `#scheduling_box`
that don't have a fixed with, so they can make the sidebar grow/shrink.
The idea here is to set the fixed width to the container so the content
is adapted instead of the opposite
Bonus: It also fixes `.o_calendar_button_today`'s margin that made it
misaligned with the `#scheduling_box`
task-3424358
part of task-3326263
closesodoo/odoo#129909
X-original-commit: 69ea739105764bccccdbee987b8f2629bf992654
Related: odoo/enterprise#44687
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
- fix tag filter
- fix product_product view in sales
- fix add to cart animation
- impove product tag view in website_sale and product
closesodoo/odoo#129901
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, in a form view with an x2many that contains an
invisible x2many, if an onchange returns a create command for the
invisible x2many field, a crash is displayed.
Problem:
The getCommands function for processing CREATE commands needs the
activeField of the x2many to be present with activeFields and fields.
Currently, the activeField of an invisible x2many has no related fields.
Solution:
All x2many fields have "related" in the activeField by default.
closesodoo/odoo#129899
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Enable the collaborative mode in Knowledge and allow portal users
to use it.
In Knowledge, there is a custom `KnowledgeHtmlField` which adds a menu
placeholder if the `HtmlField` value is empty. It evaluates if it is empty after
each `historyStep`.
This commit introduces new collaborative step events so that the
`KnowledgeHtmlField` is able to properly hide/show that menu even after a
collaborator made the value empty.
Encapsulate the `mail` ICE servers availability check in an overridable
function, since the hack does not work in a portal context, but Knowledge portal
users should be allowed to use the collaborative feature. Knowledge will
override the session check by always returning true, since mail is a dependency
of Knowledge and is therefore always installed with it.
Allow access to the edition channel for portal users.
task-3378266
closesodoo/odoo#128962
Forward-port-of: odoo/odoo#127935
Related: odoo/enterprise#44317
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
Encapsulate the `mail` ICE servers availability check in an overridable
function, since the hack does not work in a portal context, but Knowledge portal
users should be allowed to use the collaborative feature. Knowledge will
override the session check by always returning true, since mail is a dependency
of Knowledge and is therefore always installed with it.
Allow access to the edition channel for portal users.
task-3378266
X-original-commit: odoo/odoo@03e1148ac9
Part-of: odoo/odoo#128962
In Knowledge, there is a custom `KnowledgeHtmlField` which adds a menu
placeholder if the `HtmlField` value is empty. It evaluates if it is empty after
each `historyStep`.
This commit introduces new collaborative step events so that the
`KnowledgeHtmlField` is able to properly hide/show that menu even after a
collaborator made the value empty.
task-3378266
X-original-commit: odoo/odoo@b6f103bd3e
Part-of: odoo/odoo#128962
The wysiwyg component uses the ColorPalette, and gives it a callback
in props (getTemplate). This callback does an orm service call and
thus returns a promise. It is called by the ColorPalette in its
willStart, and the result (the promise) is stored in the closure of
the js module defining the ColorPalette, s.t. subsequent willStart
directly reuse the promise instead of calling getTemplate.
The problem is that the orm service (when defined via useService)
is bound to the component using it. If the component is destroyed
before the rpc returns, the promise is kept pending forever. It
might thus happen that the ColorPalette stored a promise forever
pending, leading to a screen never loading. It was for instance
the case in Invoices (list view), when you clicked on a record:
the form view might never open. In this situation, two renderings
where initiated, the first one triggered the rpc, and the second
one cancelled the first one, making the promise being pending
forever.
This commit bypasses useService to use the orm, which isn't the
best solution but it's the easiest and fastest one. Ideally, this
rpc should be done by a service, which could keep the promise in
its closure. However, a lot of test suites would need to be adapted
to make the service available for its tests.
closesodoo/odoo#129974
Signed-off-by: Géry Debongnie <ged@odoo.com>
A recent [fix](https://github.com/odoo/odoo/commit/bbcb925f88cbdc34532894918e50fd11afe7a95d) introduced a bug when trying to open
the miscellaneous operations journal from the accounting
dashboard.
A `TypeError: unsupported operand type(s) for +: 'bool' and 'list'`
was raised, which is why an empty list is used when
`action['domain']` is falsy.
Internal bug report.
closesodoo/odoo#129957
X-original-commit: ac6eee7e6c5a32b06ea9f7f21cf13623c5c85d13
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Since commit 8590c6a, the edi proxy user is no more neutralized.
Now proxy users related to l10n_it_edi are set to 'demo' mode and other users
are set to 'test' mode.
opw-3439385
closesodoo/odoo#129935
X-original-commit: 4b8759d340e7ad2ae38572f374726087db2437cf
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Thomas Beckers (tbs) <tbs@odoo.com>
This commit solves the visibility issue of an arrow in the image gallery
snippet. Before this commit, an arrow was not visible over the white
background.
In this PR[1], we adapted directional odoo icons by replacing font
awesome but there were some CSS directly targeting the `fa` class that
also should be replaced by the `oi` to target the `oi` class. So adding
the CSS selector `oi`.
- Keeping 'fa' too, as this still can be used by the already dropped
snippet.
[1]: https://github.com/odoo/odoo/commit/418413e4997a6b65eb7ad9e9ef8aba42805f1c0c
task-3339169
closesodoo/odoo#129939
X-original-commit: 59c7a371c9389135ff6fa9778e6f5adea9a97aea
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Signed-off-by: Divyesh Vyas (divy) <divy@odoo.com>
Current behavior:
When creating a loyalty program, with a rules that award points for each
dollar spent, the value of the point was inconsistent because it was
taking the rewards into account.
Steps to reproduce:
- Create a loyalty program with a rule that award 0.1 point for each
dollar spent, and a reward that gives 1$ per points.
- Create a product with a price of 265$.
- Open the PoS and create a new order for 1000$.
- Select a customer and pay the order.(The customer now have 100 points)
- Create a new order with the product created earlier, and apply the
reward.
- The value of the reward shoudl be 126.5$ (100 points + 26.5 points
from the current order) but it is not.
opw-3275585
closesodoo/odoo#129963
X-original-commit: 70256e5cf8359a09687acc3e2d4f8792ef4f9801
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
In the Spanish localization module l10n_es, duplicate tax names are
preventing the installation of demo data. This issue affects the
functionality and testing of the application for the Spanish locale.
This commit fixes it by renaming the duplicate tax names.
closesodoo/odoo#129942
Task-id: 3441003
X-original-commit: fae4a6189a02cae4cf17a28f9f2a013125a638c5
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Mohamed Erradi (moer) <moer@odoo.com>
Summary
-------
Currently, if you try to export FEC, download will work correctly, but
the UI will stay locked.
Steps to reproduce
------------------
* install l10n_fr_fec
* Accounting / Reporting / France FEC
* input a start/end date (ex: 01/01/2022 to 12/31/2022)
* click Generate
=> Report exports immediately, but the UI stays locked.
Cause
-----
This issue is caused by commit d291ef80b726c11486efe6e42d9dcf4968efa518
The intent is to make it so that if an `act_url` action with target
"self" is expected to reload the page, then the UI is blocked and
remains so, expecting the page reload to naturally unblock it. We
rely on the `beforeunload` event as a signal that the page is likely to
reload, usually followed by the `unload` event (actual reloading of the
page).
However, things are different when the new URL points to a file
download. Here, `beforeunload` is triggered, but not `unload`. As a
result, the `env.services.ui.unblock()` function isn't called, and since
the page doesn't reload, the UI stays blocked even after the download
starts.
opw-3344777
closesodoo/odoo#129918
X-original-commit: 23744ba3f992203e36dac59acfc905b018758e25
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Martin Trigaux