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>
before this commit, on calling the fields_get method of
payment.link.wizard model from xmlrpc is raising exception,
instead of returning the data
after this commit, without any traceback the requested
data will be returned to the user.
closesodoo/odoo#129927
X-original-commit: 290210d1da38b7ee19f441117aa1448a43bcc8f5
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since commit [1] (introduced in Odoo 15), when a published website page
has no URL set, the search snippet would crash when typing something
inside it.
I am not sure why was the page url not required at the model level, this
will be considered in master.
Note that to create a page without a URL, the only flow is to create a
new page in the backend.
Indeed, the `write` is overridden to add a trailing `/`, and the
frontend flows to create/write a page are also shielded against empty
URL.
Note that it's easy to create a page without a URL through legit flows.
Depending on the Odoo version, there is always a way to reach a website
page form view: either simply Website > Configuration > Pages or
Site > Pages > Debug mode > Click on Bug icon in tree view > Click on
page m2o.
Step to reproduce:
- Create a page with no URL (see above explanation how to do it)
- Make sure it's publish (you can do it in the form view)
- Drag & drop the Search snippet on a page
- Type something in the search snippet
-> TB
[1]: https://github.com/odoo/odoo/commit/9f9c4bb7e40233e633f97c60fb00ae191e9077af#diff-77bd6b19c39e211959885024bcad914655ff84cfc10c16633687d014e50aa69aR69
Fixes https://github.com/odoo/odoo/issues/129728closesodoo/odoo#129915
X-original-commit: f75ec6131eff9165b06d42d27a49dd756387f4a0
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
=== ISSUE ===
In some modules, there is a recurring layout issue with buttons being
compressed. This is caused by a missing `gap` or `margin` and
results in two main issues :
1/ It reduces the clickable zone of each button (you are more likely
to click on its neighbor rather than the one you wanted)
2/ It does not look good and causes inconsistency with other buttons.
=== AFTER ===
We simply add a `d-flex` and a `gap-1` class to the container to be sure
that no matter how many buttons are inside that <div> they will
always be spaced correctly.
task-3433602
part of task-3326263
closesodoo/odoo#129906
X-original-commit: 6fc57407478e79232e46c21e21981eeff419d884
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit addresses an issue with barcode parsing where the parser
might fail when dealing with different types of barcodes, such as
an EAN-13 barcode being parsed with a GS1 barcode parser. To improve
the user experience and add flexibility, a fallback mechanism
has been implemented.
This commit allows users to set a fallback using a system parameter.
This can be accomplished by adding a system parameter with a key equal
to 'point_of_sale.fallback_nomenclature_id'. The value should be set
equal to the barcode nomenclature id.
This provides a robust solution to enhance the reliability of the
system in various scenarios where different types of barcodes are
in use.
opw-3382121
closesodoo/odoo#129891
X-original-commit: 57a2eab4e4b8e7aac6932213611dbd4148f58bd8
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
The expand, expand_limit and expand_groupby allowed to ask
read_group to populate groups with search_read results directly.
It was only used in the list view, when `expand="1"` was set on
its root node in the arch. Since [1], the list view no longer uses
these arguments, as we uniformized the logic between list and
kanban (where groups are always opened by default).
[1] https://github.com/odoo/odoo/pull/114024
Part of task~3179751
closesodoo/odoo#129881
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
pos*: point_of_sale,l10n_ae_pos, l10n_gcc_pos
Currently, the pos receipt shows the total amount of taxes paid.
Different localisations require more information regarding the taxes
to be shown on the receipt.
In this PR we improve the receipt by adding specific information
for each of the applied taxes and a mechanism that would allow
each localization to more easily display the proper tax information.
This change makes it so the pos is in accordance with the United Arab Emirates
regulations by default. This means that we are removing the `l10n_ae_pos`
module, as we no longer need it.
closesodoo/odoo#125418
Task: 3305403
Related: odoo/upgrade#4858
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Since [1], underscore.js is no longer used in Odoo and the lib has
been removed. However, we had a customization of the lib, that is
no longer used in any assets (it would crash it it was), but that
hasn't been removed. This commit removes it.
[1] https://github.com/odoo/odoo/pull/125889
Part of task~3439226
closesodoo/odoo#129875
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Since [1], switching from one record to another in a form view
would send two `/mail/messages` rpc. This is due to the
`onWillLoadRoot` hook that triggers a `MAIL:RELOAD-THREAD` event
while the thread is going to change. As a consequence, messages
are fetched for the currently active record and the one that will
be activated.
This PR fixes the issue by ensuring the thread won't change before
triggering this event.
[1]: https://github.com/odoo/odoo/pull/114024closesodoo/odoo#129869
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Before this commit:
when new snippet is drop in mass_mailing after first delete everything and
exiting from codeview a traceback occurs.
After this commit:
Now, a new snippet can be dropped in empty mass_mailing.
Task-3178818
closesodoo/odoo#129865
X-original-commit: 8e93f3c65ada549c51b841d1f39a3422be6f3e27
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Remove ugly (light green) backgound color and use default white
2 questions per row, it was crowded to register multiple participants
Less vertical paddings on multiple tickets
UI buttons of registration dialog: both on same side
closesodoo/odoo#129863
Signed-off-by: Fabien Pinckaers (fp) <fp@odoo.com>
Before this commit, scrolling inside the messaging menu in mobile
was stuttering.
This happens because the dropdown is in full screen, and whenever
there's a scroll inside this dropdown menu, the position is
recomputed from internal `usePosition()` hook of `Dropdown`.
The repaint of recomputing this position is costly because of
using `bottom: 0` and having images in notification items that
have transparent background (e.g. chatter notifications).
This commit fixes the issue by defining the height of the messaging
menu dropdown in mobile without `bottom-0`. This drastically eases
the repainting for fixed position. `ActivityMenu` had the exact same
problem, so it is also considered in this fix.
closesodoo/odoo#129859
X-original-commit: 67af0ac45dcea55f52ee7ffbc253827d665d7ac6
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit add a small indicator in the spreadsheet's control panel
to indicate if the user's locale is different from the spreadsheet's.
closesodoo/odoo#129857
Task: 3389491
X-original-commit: 5c776994f7bd230816369be3899989e7ab780906
Related: odoo/enterprise#44665
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Multiple field visibility was not working properly while using
Multiple Checkbox field as visibility condition. Only "is equal to"
and "is not equal to" was implemented for Multiple Checkbox. The
"is equal to" uses formData.get which only retrieves the first
value from Multiple Checkbox. The Multiple Checkbox was not having
"contains" option which was already available for some other
fields.
This commit will implement "contains" for all the input types
which comes under hidden_condition_no_text_opt in the file
s_website_form.xml. These include radio, checkbox and Multiple
Checkbox. The fields which comes under hidden_condition_no_text_opt
which does not require multiple inputs can use "contains" and
"doesn't contain" interchangeably with "is equal to" and
"is not equal to"
Fixes#120631closesodoo/odoo#129853
X-original-commit: 696d74e5304bd48e965a1c5f5fc0b5a5205f5d49
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Current behaviour before commit:
shiftTab doesn't outdent the styled text.
Desired behaviour after commit:
Now styled text gets outdent by shift + tab.
task-3283175
closesodoo/odoo#129844
X-original-commit: 1a438fa3f29794a44cda57917d2133b439c3fd0a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Improve low-level checks of recipients in mail asserts. Sometimes 'email_to'
cannot be easily deduced from given input (partners, records customers, ...)
when some record -> email transformations are involved e.g. when dealing
with multiple emails input, double encapsulation, ...
Those tools are about to be used in upcoming tests and fixes.
Task-3438381 (TestMail: backport tools)
Prepares Task-2612945 (Mail: Defensive email formatting)
X-original-commit: bdbe846329ed51e4c5e3b75740e8f594edf7b138
Part-of: odoo/odoo#129839
PURPOSE
Purpose of this commit is to backport some improvements done in mail testing
tools done in newer versions. Some of them are required for incoming tests
to be added, other just to try to ease writing tests across versions.
SPECIFICATIONS
Partial backport of odoo/odoo@94208cb8b4
Improve finding outgoing mails and emails when batch methods (mass mailing)
create similar emails, that can be distinguished notably by the subject
in addition to from / to.
Partial backport of odoo/odoo@c98f259736
Add a method to check MailMail, based on a given record. When having duplicates
to differentiate in a given mailing, having just recipients is not sufficient
as multiple emails may match a given recipients list. Checking model / res_id
is another method for finding emails.
Partial backport of odoo/odoo@a3e404e17e
Add some information and values propagation in some custom asserts in mail
test tooling.
Partial backport of odoo/odoo@b915617569
Allow to return <mail.mail> records and found outgoing emails when using
asserts. It eases doing checks in some specific tests e.g. checking
notification layout usage in emails. Indeed this is quite low level and
does not really deserves its own assert tooling methods.
Partial backport of odoo/odoo@bbf4783ac6
Improve checks and asserts done when asserting content of produced
mailing content (mails, traces, ...).
Task-3438381 (TestMail: backport tools)
Prepares Task-2612945 (Mail: Defensive email formatting)
X-original-commit: 2bc28c804a92f206133c352c046dcdd4971fd4a6
Part-of: odoo/odoo#129839
Problem
---------
Some Unit of Measures need to be configured when using the Mexican
Localisation to be used in their electronic invoicing system. As of now
they are not installed by default but many businesses will need to add
and configure them manually. Let's make those included in the l10n_mx
localisation.
Objective
---------
Addition of the Service UoM category and the 3 UoMs in the UoM data file:
- Service Unit
- Activity
- Job
Solution
---------
UOM category and units were added in an XML file in the data folder.
Translation added to the uom.pot file to be translated later;
translation already added in es_MX since the task is targeted at Mexican
localisation.
task-3392056
closesodoo/odoo#129672
X-original-commit: 0f88914a4618aa1abd250b6cf701a5f7b381f41e
Related: odoo/enterprise#44590
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Antoine Boonen (aboo) <aboo@odoo.com>
Before this commit, the record.update function did not allow x2m fields
to be updated. Thanks to this commit, you can update an x2m by passing
a list of commands that will be applied to the x2m's static list.
This makes it possible to update several fields, including x2m fields,
while triggering only one onchange to the server.
closesodoo/odoo#129507
Related: odoo/enterprise#44532
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Mahdi Cheikh Rouhou (macr)