Before this commit:
When the user creates new stages or groups in Kanban view and adds new tasks
with particular states and then if the user clicks on any colour in the
progressbar then the filter gets applied on all the groups or stages.
Observerd Behaviour:
The filter is applied on all the groups or stages.So, if we click on a colour
in the progressbar suppose colour Green to filter out Approved task(s) of a
particular stage then in that stage or group only the Approved task(s) would be
visible. Also the filter would get applied on all other stages or groups created
at that time. In those stages all the task with that state would be visible and
rest of them would get blurred.
Steps to produce:
- Install `Project` and add a new project in it.
- In the newly created project add some new stages or groups, each consisting
some new tasks.
- Give some states to those tasks through project state selector
(for eg: Approved, Changes Requested).
- Click on any particular colour in the `Progressbar` of any particular group or
stage.
Expected Behaviour:
When the user clicks on any colour in the progressbar then it should filter out
only those tasks which are associated with that color/state and only in that
particular group or stage.
Reason:
https://github.com/odoo/odoo/blob/579ee6d9792050955fa80346fd57ad294efcdd62/addons/web/static/src/views/kanban/progress_bar_hook.js#L114
group.serverValue results as Undefined. Because when the data is being prepared
here:
https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/dynamic_group_list.js#L222-L231C11
there is no serverValue provided. So, whenever a group is getting created
here serverValue `Undefined` as value.
https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/group.js#L25
Note:
- There was a need to change the function name from
`getServerValueFromGroupData` to getGroupServerValue as now now this function
calculates serverValue while the data is being created and not when the data is
already created.
- The function is exported into another file as this function defines the basis
to calculate serverValue and there is a necessity to calculate serverValue while
data is being created.
Task-3620697
closesodoo/odoo#149694
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When reading values in reactive objects, Owl's reactivity system will
return reactive versions of the sub-objects to allow tracking reads in
depth, so that changes to values in deep object hierarchies can still
cause components to render themselves if needed.
Luxon objects are immutable. Since they cannot change and values inside
them cannot change either, tracking reads within luxon objects is pure
overhead.
This commit makes luxon objects non reactifiable by setting the
Symbol.toStringTag property on the luxon classes, which is what Owl uses
internally to determine if objects can be made reactive. It will also
cause some of these objects to serialize to more specific strings
instead of just [object Object], eg [object LuxonZone].
closesodoo/odoo#153540
X-original-commit: ac58cb22cd8b275f89bf387a6cea8144ce26ee65
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Issue:
======
Some templates that contains an image have wrong width and it can't be
updated.
Steps to reproduce the issue:
=============================
- Use a view with width < 1135px
- Go to email marketing
- Create a new mailing
- Use the welcome message template
- The size of the signature is wrong and you can't update it
Origin of the issue:
====================
There is an applied style which fixed the minimum width to 100% if the
img is alone inside the parent element (has no siblings)
https://github.com/odoo/odoo/blob/749133f3170f795c9deabc6ad6f7684baa76db59/addons/mass_mailing/data/mailing_data_templates.xml#L98
Solution:
=========
Add `img-fluid` class to some `img` elements to keep the layout correct.
task-3718618
closesodoo/odoo#153508
X-original-commit: 1126a8103d56b8587b793735f08b4a5917a0d15c
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Prior to this commit, Gift cards assigned to a specific partner were
restricted for use only by that partner. This commit rectifies the
issue, enabling Gift cards to be usable by any customer as intended.
opw-3689391
closesodoo/odoo#153507
X-original-commit: 15c79c3f46bcc6787efc950bd3a9a122b298f919
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Previously, the order line quantity would inadvertently update if the
Customer list screen was opened without clicking the search bar and
typing numbers. This commit resolves the issue by disabling the event
handler while a temp screen is open. Also, it enhances usability by
focusing on the search bar upon opening the Customer list screen.
opw-3634910
closesodoo/odoo#153506
X-original-commit: d792bb4b28c16b19452b7dcf06e73459ed9b8312
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Have a grouped list view s.t. there's a group with enough records
to have a pager in the group. Go to the second page of that group.
Then, apply a filter such that there's only a single page remaining
in the group. Before this commit, no record was displayed, because
the previous offset wasn't reset to 0 it should have been. With
this commit, the offset is recursively reset, so we correctly
display the records of the first page after a reload.
closesodoo/odoo#153494
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Description:
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in
case of `auto_join=True`), which is inefficient, as the `id` can be
retrieved directly from the current `model` table, instead of going
to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule`
of the `comodel` is applied, which is not the case when directly
referencing the `field` from the `model`. So in some cases using an
explicit `.id` would be a wanted, if the intention was to apply the
`ir.rule`.
Fix:
Remove the `.id` from left leafs of domains that if the field is
stored, and the `comodel` doesn't have `ir.rule` associated with it,
or the `ir.rule` application is redundant/not needed.
task-3735923
closesodoo/odoo#153450
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
The version of werkzeug installed can vary from one deployment
to another, as we recommend to use the operating system package,
and the version can therefore change according to the operating
system version.
e.g. the werkzeug version installed using
`apt install python3-werkzeug` varies between
Ubuntu 18.04, 20.04, 22.04, 23.10, ...
We want to keep under control the attributes
developers use on werkzeug.wrappers.Request,
to avoid compatibility issues from one
version to another.
Therefore, this revision aims
to subclass werkzeug.wrappers.Request to limit
the attributes which can be used.
task-3734305
Part-of: odoo/odoo#78857
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
In order to not add steps in the history when changing the slides of a
carousel, commit [1] added listeners that would deactivate the observer
when sliding and reactivate it when the slide is over, in the `slider`
public widget. These listeners are then removed at destroy.
However, the way they are removed breaks some of the carousel behaviors:
- Drop a "Carousel" snippet.
- Change any "Carousel" option (so not a "Slide" one). For example, set
the "Height" to 50% or add a conditional visibility.
- Slide the carousel (with any arrow).
=> The slide number did not update correctly.
- Remove a slide with the "-" button.
=> The slide was not removed.
It happens because, when this widget is destroyed, it removes all the
`.carousel` listeners, which means that it also removes the listeners
added at the `Carousel` options start. And since the widget is destroyed
and restarted every time an option is changed, but the "Carousel"
options are started only once at the beginning, the removed listeners
are never added back (until the next start of the options).
This commit adds an id to the events managing the sliding history, to
make them more specific, in order to only remove these ones when the
widget is destroyed.
[1]: https://github.com/odoo/odoo/commit/14bc1a9bd1ebdec3b73e268450267320b79d01cd
opw-3675019
closesodoo/odoo#153578
X-original-commit: 041935aff660ae5df1220e3d844d2a2cbcf4ee5c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
To reproduce:
- Put your fiscal year to the 30th of December (yes it's unlikely)
- Create an asset
- Compute depreciations
=> they are created for the 31th of December
It comes from the `get_fiscal_year` in `date_utils` which considers it as the case of the 28th of February
opw-3704466
closesodoo/odoo#153528
X-original-commit: cd0bb178441790e7e33c0d1c01b7ade82d4ab8c0
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
It is possible to have context keys being leaked from outside the
context manager in the following case:
* a new transaction starts with a new environment
* the code calls `_disable_recursion`
* all the existing environment are modified with the context key
* inside of the context manager, a new environment is created without
specifying a full context: we keep the previous one, which contains
the context key
* the code exits the context manager and cleans all the environment it
was aware of <-- this is the issue
* the environment that was created inside the context manager still
contains the context key, if it is used and is never cleaned.
Now, we also remove the context key of all the environments created
inside the context manager.
It is better to risk having some recursion (probably leading to
operations being done multiple times) than doing nothing at all because
the context disables some features.
closesodoo/odoo#153526
X-original-commit: 664ae6b1a4dceca2d77eca8d8a24d47c6b3949a7
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Summary:
========
1. Handle the inverse fields of `account.full.reconcile` manually
2. Batch the update of matching numbers
3. Batch the balance consistency test
4. Batch the construction of reconciliation batches
5. Precompute fields on partials
6. Avoid recomputation of same default analytic distributions
7. Cache the accounting date wrt lock date
1: Handle the inverse fields of `account.full.reconcile` manually
-----------------------------------------------------------------
In order to update the inverse fields of `reconciled_line_ids` and
`partial_reconcile_ids`, the ORM is triggering one query per full
reconcile record. In the case of a big batch payment, that is a lot of
round trips.
This also bypasses the computation for possible tracking, which is
expensive to do for 2 records at a time. That field is not tracked
anyway.
2: Batch the update of matching numbers
---------------------------------------
Basically the same as 1. without the tracking.
3: Batch the balance consistency test
-------------------------------------
Use the various context managers around `__reconcile_plan` to check for
the balance consistency only at the end in one single query. This avoids
checking it at every single intermediate write done on the lines.
Also doing it for the sync of dynamic lines. It should be useless but it
doesn't cost anything, and allows to remove the context keys in
enterprise without a cost. (they shouldn't be used explicitly, the
context managers should always be used instead)
Using these context managers also allows to remove all the `skip_`
context keys, which should not be used: using them will mean that as
soon as the journal entry is modified for any reason, some business
fields will change because of the synchronisation since the context
won't be the same anymore.
This commit therefore also makes `_sync_dynamic_line` more resilient and
avoids even more useless syncs.
4: Batch the construction of reconciliation batches
---------------------------------------------------
Introduce `_reconciled_by_number`, which is basically a `_read_group`.
In conjuction with `_filter_reconciled_by_number`, we can find all the
reconciled lines in one single query, for as many batches as needed; as
opposed to one query per batch before.
5: Precompute fields on partials
--------------------------------
Simply avoid doing one batched `INSERT INTO` followed by one `UPDATE` for
each record.
6: Avoid recomputation of same default analytic distributions
-------------------------------------------------------------
Not really linked to the reconciliation, but when a lot of lines are
using the same parameters for the default analytic distribution, it is
useless to re-compute it multiple times.
Can speed up the population of test data for instance.
7: Cache the accounting date wrt lock date
------------------------------------------
When preparing the create values for the exchange moves, computing the
date with regards to the lock date once per move is very expensive.
By creating a context dependent field, we can cache the value and avoid
doing the same operation multiple times.
Benchmark:
==========
We are testing 2 use cases:
* a lot of small matchings that are producing a full 2 by 2
* one big matching (also producing a full)
To reconcile a batch payment of 500 (identical) lines in the bank reco:
| | Queries | SQL | Other |
|--------|---------|-------|--------|
| Before | 4191 | 4.649 | 16.253 |
| After | 226 | 0.989 | 3.581 |
To reconcile one big batch of 1000 lines with the generic reco widget
(spaghetti):
| | Queries | SQL | Other |
|--------|---------|-------|-------|
| Before | 82 | 0.478 | 1.131 |
| After | 66 | 0.634 | 0.974 |
To reconcile a batch of 1000 lines *in foreign currency*
| | Queries | SQL | Other |
|--------|---------|-------|-------|
| Before | | | |
| After | 45995 | 125.0 | 146.3 |
All the times are in seconds.
We can see the the use case of the batch payment is improved a lot (the
time is expected to be linear with regards to the number of payments),
while the time for big batches is not impacted.
closesodoo/odoo#152284
Related: odoo/enterprise#55633
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps:
- Install project.
- Go to settings and select Custom Email Servers.
- Add alias domain.
- Then go to the project.
- Create a new project.
- The gap between the email alias and project title is too much.
Issue:
-When we create a new project the gap between the email alias and project name is too
much when only the project is installed and there are no options to display.
Cause:
-The "margin-top-4" taking much space.
Fix:
-After this commit the space between email alias and project name is decreased
by changing the space.
task-3550638
closesodoo/odoo#153277
X-original-commit: b01b2f2f4d2e31648e3c98b8991eaafc886ca542
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
A user that is not admin cannot create an mail.alias.
We can create the alias in sudo since we control the default_values and
model that are created with the new alias.
Check the _check_alias_domain_id_mc constraint in sudo because non amdin
user cannot read model ir.model.
closesodoo/odoo#153222
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Steps to reproduce:
- insert a global filter with double quotes in its name (e.g. my "special"
filter)
- reference that filter with ODOO.FILTER.VALUE (remember you have to escape
the " in the formula with a backslash \
=ODOO.FILTER.VALUE("my \"special\" filter")
=> the filter is not found
closesodoo/odoo#153337
Task: 3697855
X-original-commit: 83826d3546ff584c5ff22021370f572787d032bc
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
In this commit, the mobile/phone number is in sync with the partner
if the partner is not there then it will be generated based on the applicant
information
Task-3635976
closesodoo/odoo#150820
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Oversight in 06919a232251cbd68a28500757aef5cd2e3363a0
Need to handle `default_child_ids` and `default_tag_ids` as well.
closesodoo/odoo#153397
X-original-commit: 7d521b129c82e38afe50cd8b81cb2081c157aceb
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this PR, the `test_complete_chatbot_flow_ui` would sometimes fail
when checking if the user can add a reaction to a message.
There are two issues:
- This step uses the `contains` helper and specify the live chat `ShadowRoot`
as the target. However, the `contains` helper uses a mutation observer
that observes the light DOM thus, changes in the shadow root are not
correctly observed.
- The target passed to the `contains` helper is the `ChatWindow` DOM
element but this element can be unmounted in-between.
This PR fixes this issue.
fixes runbot-56670
closesodoo/odoo#153382
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit addresses an issue where, upon application to an invoice,
the Receivables, while accurate in terms of Amounts and Due Dates,
have incorrect labels.
The root cause of this problem was identified in the compute_name method
of the account.move.line model. The modifications in this commit
rectify the compute_name method to ensure that payment terms labels are
computed correctly.
task-3636484
closesodoo/odoo#153364
X-original-commit: 59c0350b55b11321ba49e1ae4124eb5828d5f665
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce
- Install Sales, Accounting and purchase apps
- Go to Settings and activate Analytic Accounting option.
- Create a product that can be expensed and that is re-invoiced at cost + add cost
- Create an SO with another product and add an analytic account (activate analytic accounting if not activated by default) + confirm
- Create a PO with the expensable product and add the analytic account in the PO lines
- Receive product + create bill
- The product is added in the SO with 0 quantity and if I change the quantity to one, the price is recomputed according to the sales price (instead of taking into account the cost).
Investigation
- The `_compute_price_unit()` method doesn't take into account if the so line has been expensed or not
opw-3671812
closesodoo/odoo#153358
X-original-commit: 059b19c59a9222b676be5246eb94d680cf6bf27b
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
Before this commit, users without admin access rights were unable to
generate invoices.
opw-3701291
closesodoo/odoo#153350
X-original-commit: 27ad4379364b481276a6597bb9fab9778f07fd5f
Signed-off-by: William André (wan) <wan@odoo.com>
Addresses the issue where mandates returned by Stripe were not
being saved in the database, rendering them unused. The fix
involves retrieving mandate information from the charge object
in Stripe, as the mandate data is included in the payment method
details of the charge object, rather than in the payment methods
object.
task-3594745
closesodoo/odoo#153329
X-original-commit: 1db395eb8a12058702b5e7dbd7213c65ae2ac52b
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Previously, when changing the tag of a text node within a list, it transferred
the list's attributes to the newly created tag. Ideally, this should only carry
over the attributes of paragraph-related elements and not of lists.
task-3609500
closesodoo/odoo#153328
X-original-commit: 58829be8fee0d3330427a467c62280b6d6edb147
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Commit [1] changed the code in toggleList such that variable block could not be
a block. This commit updates the name of variable block to nodeToToggle.
[1]: d314fb6a6ceb6bade38a2a6b3e0e2e3fd016b7d9
task-3609500
X-original-commit: b863fff7d8e62dc28d8e5de20dffea6896dc188a
Part-of: odoo/odoo#153328
Prior to this commit, adding more than one pricelist to the available
pricelists and attempting to create a partner from the Point of Sale
would result in an error.
opw-3703269
closesodoo/odoo#153314
X-original-commit: 462ff7c657c22c29ffc2c522afdc9fd99068d6fb
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Steps to reproduce
------------------
* create the following hierarchy of companies:
```
Company
└── Branch A
└── Branch B
```
* delete `Branch A`
From then on, whatever you do will result in a Bad Request response.
opw-3662711
closesodoo/odoo#153264
X-original-commit: da803db384ec809a9c68dd379bf3c03f00d5a731
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
So far when new employee was created from applicant he got a mail
with notification about employee creation. It's not a desired behaviour
so this change makes just a log note about it.
task-3621545
closesodoo/odoo#153227
X-original-commit: 7b1dce2ef4a47870897847fb06ba8fe3cb199109
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps:
- Create an automation rule with a model X
- Delete model X (need a way that keep the rule)
Actual result:
- Crash due to warning message
Expected result:
- Warning message is logged without issue
opw-3722953
closesodoo/odoo#153078
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Steps to reproduce the bug:
- Create a storable product:
- Unit of Measure: KG
- Purchase UoM: Tonne
- Vendor: “Azure Interior” Quantity: 6T
- Recording rule: Min quantity= 500
- Trigger: Manual
- Route: Buy
- Go to the replenishment page:
- Click on the “i” icon
- On the Azure Interior line, click on “Set as supplier”
Problem:
The quantity to order is not updated to 6000 kg because in the
"action_set_supplier" function, we compare the quantity of the supplier
information with the quantity of the orderpoint without converting the
values to the same UoM. So:
500 < 6 → False
Therefore, the quantity is not updated.
Opw-3705090
closesodoo/odoo#153300
X-original-commit: 9c0550a223b155e4e0859f87d94c1229b53c824a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce issue:
1. Open CRM and select a list/tree view (opportunities or leads)
2. Select multiple records and try merging them (gear menu)
3. Click on salesperson field
4. Field dropdown contains portal users, should not be the case
Explanation:
`user_id` (salesperson field) in `crm.merge.opportunity` is a many2one related to res.users. Since it is not restricted, every existing user is listed in the selection.
Suggested fix:
In `crm.lead`, its homologous field possesses the domain formula `('share', '=', False)`.
https://github.com/odoo/odoo/blob/f987dd26e928bd0394cd0b835cc1d0fdd72e9234/addons/crm/models/crm_lead.py#L105-L108
Copying it into `crm.merge.opportunity` correctly restricts the users selection.
opw-3696148
closesodoo/odoo#153230
X-original-commit: e43d13d8aae2b46107237102e9f45a4c8e8e39df
Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>
Previously, In RTL mode, the table columns menu were misaligned, causing a
visual discrepancy in the UI.Now, Implemented a fix to correctly position the
table menu columns in RTL mode, ensuring proper alignment and resolving
the visual misalignment issue.
task-3695715
closesodoo/odoo#153327
X-original-commit: 331f95265f6ba04369b654811cd594cc083a54d9
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Aashish Thakur (aath) <aath@odoo.com>
To reproduce
============
- Go to shop
- in edit mode select a product
- add a ribbon or modify it
- save -> ribbon is not saved
Problem
=======
When changing the ribbon, there is no editable item that is marked
dirty, because the ribbon doesn't have a savable parent.
Solution
========
Flag the ribbon as dirty manually to trigger saving process
Note: the reason why this is needed in 16.0 and not before is [1].
Before that we did not check for the presence of the dirty flag (the
"o_dirty" class) to determine if the page has to be saved. All of this
has to be reviewed in the future, as explained by [2] and its following
commits. Note that commits like [2] is probably the cause of ribbon not
being savable anymore: parts of the DOM stopped being flagged with
o_dirty by mistake... so the saving process was not triggered "by
mistake" anymore. At the time of [1] for example: just clicking on a
product image (to maybe then add a ribbon) was enough for it to be
marked with the "o_dirty" class by mistake. This was probably solved
later... creating the bug being solved here.
[1]: https://github.com/odoo/odoo/commit/650a97d1bd59254cc2115d54d58940b6112a8d70
[2]: https://github.com/odoo/odoo/commit/e8a86b860dcba5b7782fc26c4290eee48d9fcdee
opw-3674520
closesodoo/odoo#153298
X-original-commit: 34876a321ac491c1bede1e36d0cca6248af2a86c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In the commit 671640c part of the commit 6ae9c9c was removed
inadvertently. After this commit pickup locations will be displayed when
the delivery carrier is pre-selected.
closesodoo/odoo#153259
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce:
1. install the calendar module
2. in General settings, add the French -or any- language
3. create a new event
4. under **Options** tab choose the recurrence type to be weekly
5. select the days to repeat the event on
6. save the event
7. send an email using the **EMAIL** button, you can notice that works like (Weeks) and the days’ names are not translated but still in English
Investigation
- the translation is applied on the model level, not on the code level. So we have to explicitly/programmatically translate the options.
Discussion
- In the proposed fix, we compute the recurrence rule `name` by translating it to the current language -the event creator's language- but as this field is **stored**, it resulted in another issue that the invitation emails sent to the participants had a mix of languages: the email template being translated in each participant's language while the recurrence rule itself is translated in the owner's language being a **stored** field
- That's why the fix got extended to embed translating of the recurrence rule directly into the template.
- However there's a **_limitation_** we couldn't deal with that's there are two types of emails we are concerned with:
- invitation emails that follows `calendar attendee` model which works correctly as discussed
- update emails that follows `calendar event` model coming from the composer which deosn't allow to properly use partners/participants languages
Resolution
- The update emails are sent in the owner's language, with the intention to enhance the behavior in master (Task-3677327)
opw-3483319
closesodoo/odoo#151669
X-original-commit: 1d6d12ab67ffc96719c3c329cdba1cc3e3471f36
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
Steps to reproduce:
- Create a new purchase tax and archive it
- Create a new PO
Bug:
the archived tax is still sugested on the PO Line
Fix:
apply same logic as for sales
opw-3701429
closesodoo/odoo#153156
X-original-commit: 79e0c4383fe72b5d04af8a81b57a65044a91d273
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Currently, the user does not get any feedback if the printer couldn't print.
This can happen when the printer identifier is not the same on CUPS and on the IoT box due to this RegEx:
https://github.com/odoo/odoo/blob/5b62e301b91a3f39857c2c7f18729e10796ef194/addons/hw_drivers/iot_handlers/interfaces/PrinterInterface.py#L55
After this commit, an error message is displayed in the IoT box logs so the user is informed that the printing failed.
Also, the '-' character has been added to the RegEx as it is a commonly used character in printer's identifier as CUPS doesn't allow spaces.
opw-3458347
closesodoo/odoo#153148
X-original-commit: 722a7db800b66db2d0b735ced1b9f4074ddac611
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
How to reproduce
1. Log in as Mitchel and go to a Subscription dashboard
2. Copy the URL and paste in incognito
3. Log in as Marc (which does have access to the subscription dashboard)
--> Traceback
closesodoo/odoo#153143
Task: 3581647
X-original-commit: 1c4b6b0a491d63d1f1b6c7a21089a42d4bfd64ab
Related: odoo/enterprise#56107
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
It appears that some user need to have the german translation on the dutch
localisation. This commit will translate the following files:
- COA
- Taxes
- Fiscal position
- Tax group
- Tax report
closesodoo/odoo#151296
Task: 3682464
Related: odoo/enterprise#55207
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
If translation of '__export__' module record's source and translated value in
'en_US' language is different. In that case, record's value of en_US lang is
translated value. Also in most of the case export module records are set as
noupdate false due to this while upgrading the database to version 16 from lower
version, the record's value is changed to their source value for 'en_US' lang.
To avoid this problem of updating a record's value, this PR will not considering
'__export__' module records for translation updates. Hence,'__export__' module's
records translation remain same as per original database.
Task : 3626386
closesodoo/odoo#148757
X-original-commit: 29341902bd6b6b7ff84eede2651251f6d2ce2faa
Signed-off-by: Raphael Collet <rco@odoo.com>
This commit fixes the problem of selection change on colorpicker fast
hover.
Before this commit, hovering too fast on the colors of the colorpicker
unselected text that would be on the edge of the selection and
uncolored. This is fixed by deep ranging the selection at the moment we
limit it to fonts. This improves the accuracy of the history as, in case
the font tag has been removed, it saves the text node as the current
selection. And since hovering updates rely on it, it prevents losing the
selection when unhovering fast (which is the cause of the bug).
We noticed two behavior when dealing with this bug. When hoving on a
color cell and exiting out of the colorpicker altogether, no bug
appears. But when switching between two cells, multiple selection issue
happen. After analysis of the performance graph, we believe that this is
due to the fact in the first case, onSelectionChange events are fired
and the handler is called, whereas in the other case it doesn't happen.
That handler particularly reacalulates the latest selection. And this
doesn't happen in our pathological case. After testing this theory, we
view that the problem is solved.
task-3295858
closesodoo/odoo#153212
X-original-commit: 9e3ee2563021b70ce64e7ec010b149820014bf8d
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Co-authored-by: Hamza Maimoune <hmai@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Previously, sanitize would remove the `<p>` tag if it was a child of an `<li>`
element. This commit makes sure that the `<p>` tag which is a child of `<li>`
with class `nav-item` does not get removed.
task-3609500
closesodoo/odoo#153211
X-original-commit: bbc980637bd104b69fcbe0452fad9be0d92288d2
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
The mega menu templates on the website, like `s_mega_menu_multi_menus` and
`s_mega_menu_menu_image_menu`, contains a `text-center` class within the `div`.
This div has multiple block type anchor nodes. When a list is added to the mega
menu, the anchor node is added inside the `LI`. Now clicking on the `A` tag then
adds the `oe_edited_link` class, resulting in the centering of the A tag due to
the `inline-block` display of the `oe_edited_link` class. This commit fixes the
issue by adding display `inline-block` when not with nav-link.
task-3609500
X-original-commit: d2d9e53b9165ab51078a9035850182132fa4a75c
Part-of: odoo/odoo#153211
Commit [1] implemented an approach to preserve all the attributes when
converting to a list. This is beneficial for `p` elements since they will no
longer be in the DOM. However, elements other than `p` will always remain,
requiring only dir attribute and not other attributes like href, data-name,
describedby, etc.. to transfer to the list.
[1]: c422db596d909efc5ae0ba049f8f9f5b80a90883
task-3609500
X-original-commit: 3b1cd38bf69cb91789d2b66070effab465a2a6c6
Part-of: odoo/odoo#153211
When inserting a list to a mega menu, the closest `LI` is a nav-item within the
navbar. We aim to prevent the toggling of this list. This commit ensures that
lists with class nav-item in the navbar are not toggled.
task-3609500
X-original-commit: a64a37aeeb5c6f6eb838cf5b9c4221e8522721cf
Part-of: odoo/odoo#153211
__Current behavior before commit:__
The `find` jQuery method calls at some point `apply` on the results.
Sometimes however the number of results can exceed the maximum number of
arguments given to a function.
In such case `RangeError: Maximum call stack size exceeded` is thrown.
__Description of the fix:__
Instead of selecting all children with `find('*')` and filter them
afterwards with the selector, we find all the elements that match the
selector in the closest `<body>` parent and then we keep only those
contained inside `$from`.
opw-3703963
closesodoo/odoo#153161
X-original-commit: 2667c8d42c5ac18257975e166a2aea254416e3fa
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Julien Launois (jula) <jula@odoo.com>
Before this commit, if a public holiday was created on dates overlapping
an existing validated leave, the timesheet entries for the public
holiday would not be created as they already existed for the leave. If
the leave was then refused or cancelled, the timesheet records linked to
it would be removed and the employee would have missing timesheet
entries for the public holiday.
This commit fixes this behavior by recreating the public holiday
timesheet records for the affected employees when refusing their leave.
opw-3550523
linked to com: https://github.com/odoo/odoo/pull/145522closesodoo/odoo#153118
X-original-commit: 47b4763ad948686e0e7155b3c0b3d0dc4d970963
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
sami odoo