The string value of an empty array is `""` which is falsy. Prior to this commit,
if all optional columns headers were disabled in a list view, it would result in
a reset of those when the view is mounted the next time, instead of keeping them
disabled like in prior versions.
task-3692178
closesodoo/odoo#153831
X-original-commit: e600ed2fa2f2e612dfca20872356ae926dde0a54
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
Since fd2fb212c5, the
sepa provider (enterprise module) behaves as a custom
provider but despite some adaptations, the removal
of providers on module uninstall was not properly
adapted.
The uninstall of the sepa provider failed as its
inline template was not unlinked from the provider
before the template deletion.
This commit makes sure that custom providers are
correctly considered in the uninstall util supposed
to restore a provider to its state before the
installation of its module.
opw-3734697
opw-3721846
closesodoo/odoo#153843
X-original-commit: e70dbbae56472b124a59c38a1fbfeea23c8ec28b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
- Go to Website > Add menu items in a way that activates “auto-hide” (to
set the overflowing menu items in a “+” dropdown) if the viewport was
resized.
- Go to “edit” mode (adding the sidebar reduces the current window
width) > The “auto-hide” menu adaptation is disabled, and overflowing
menu items are still visible.
On [15.0 - 16.4]:
The original commit fixed the behavior described above by preventing the
unbreakable mechanism from detecting header changes and canceling the
auto-hide updates (see: [X-original-commit]).
In addition to the main fix, some other changes were also added to allow
correct editing of extra menu items [1]:
- The `_adapt()` debounce was replaced by a throttle that applies the
first menu adaptation immediately.
- We remember the state of the extra menu dropdown (open or not) if it
is there, which will be restored after the menu adaptation.
- When clicking inside an extra menu item, The extra menu is closed. We
prevent this default behaviour in "edit" mode.
Starting from 17.0:
The code from [2] fixed the same editor's rollback issue by using a
`withoutRollback()` to ensure that the `_adapt()` is called without
triggering any rollback.
This commit will only forward-port the adaptations from [1] since the
rollback issue was fixed using the new `withoutRollback()` tool.
[2]: https://github.com/odoo/odoo/commit/cbed990924887eb529056d89a042a92ba27b825b
Related to opw-3484742
closesodoo/odoo#153566
X-original-commit: 4713f95f18d7326b553464c0be6fdcd68b330292
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since commit [1], it is now possible to order the columns in mobile view
independently from the desktop view. When moving a column with an arrow,
if we are in mobile view, mobile order classes are added on the columns,
which only changes the order on mobile without affecting desktop. But if
we move on desktop view, then these classes are removed.
While it works well when using the arrows, this behavior is not the same
when moving the columns with the drag and drop. This means that drag and
dropping a column
- in the same snippet does not reset the mobile order classes;
- in another snippet does not reset the classes in it and does not fill
the gap left in the previous snippet if it was ordered.
This means that in the same snippet, there can be both columns with and
without the mobile order classes. This causes some issues:
1) Removing such snippets or their ordered columns causes a traceback.
Indeed, the `onRemove` code considers that all columns have the mobile
order classes if we remove one, which is why it fails when it is not the
case.
2) The arrows on the mobile overlay are not always correct and can also
be missing, because they depend on the order classes.
3) In mobile view, changing the order of the columns adds inconsistent
mobile classes on them, because of the columns that already have one.
This commit improves the drag and drop by also taking mobile ordered
elements into account, as it is the root cause of the mentioned issues:
- When a column is moved, the order classes of all the other columns in
the snippet where it was dropped are removed (so it behaves the same way
as with the arrows).
- When moving an ordered column in another snippet, the gap it left in
its previous snippet is now filled.
This commit also fixes the issues for already dropped blocks in existing
DBs, by
- adding a check when removing to avoid the first issue;
- removing the mobile classes at the start if they are inconsistent.
[1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba
opw-3697962
closesodoo/odoo#152487
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, an Outlook event without an organizer would fail to
sync with Odoo. This commit fixes this issue by allowing events without
an organizer to be synced from Outlook to Odoo.
opw-3701839
closesodoo/odoo#153683
X-original-commit: 4f441aa083413e475728f4f510afdbb9f15a26ef
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Issue:
- When a Helpdesk ticket is associated with a partner, this association
is not being correctly linked in the Timesheet module. As a result,
when attempting to group Timesheet entries by partner, the grouping is
inaccurate.
- The issue is caused by the '_compute_partner_id' not being triggered
due to the 'partner_id' being set in the '_timesheet_preprocess' method.
Steps To Reproduce:
- Go to Helpdesk
- Click on any project with the timesheet option enabled.
- Click on new
- Add title, customer and timesheet hours
- Go to Timesheet
- Group by 'partner'> the customer is not there
Solution:
- remove the lines where partner_id is set in '_timesheet_preprocess'.
opw-3667921
closesodoo/odoo#153740
X-original-commit: 811e84289952a0398f47aafb54f623664e8e191f
Related: odoo/enterprise#56446
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Kawtar Drissi El Bouzaidi (kdeb) <kdeb@odoo.com>
Steps to reproduce the bug:
- Add an "Image Gallery" on the website.
- Add a new image on the snippet.
-> Problem: the thumbnail of the first image of the carousel has been
replaced by the new added image.
To solve the problem, the triggering of the `image_changed` event has
been removed on extra image added. It was introduced by [1] to trigger
the re-rendering of the thumbnail when adding a new image on the
carousel but was actually useless. Indeed, the mechanism was the same as
now; when a new image was added on the carousel, the
`website.gallery.slideshow` that already handles the thumbnails was
re-rendered. An important thing to note is that the system was also
never intercepting this `image_changed` event as it was triggered on an
element that was not in the DOM (as it was removed at the
`_replaceContent()` call in the `slideshow()` method). However, since
[2], the images rendered by the `website.gallery.slideshow` are replaced
by the images (or the wrapped anchored images) returned by
`_getImgHolderEls`. Therefore, `$newImageToSelect` is part of the DOM
and the `image_changed` event is intercepted by the gallery option. As
the active carousel item is always the first one of the carousel after a
`website.gallery.slideshow` re-rendering, the system changed the
thumbnail of the first item with the new added image.
[1]: https://github.com/odoo/odoo/commit/85990768592cbdefbb178b5ffa38c1e29b9eeb87
[2]: https://github.com/odoo/odoo/commit/0fd2477d993e822fe6fd4497aace9f746af7a481
task-3736301
closesodoo/odoo#153717
X-original-commit: 3c4239212e7bedc3cb49f34d9eb0a23c3de0cbd6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
In commit[1] we changed the spacing of the activity button to dissociate
it from buttons that are "message/communication" oriented.
This spacing was unwanted so we need to revert it back.
task-3730089
[1]: odoo/odoo@e0491c1a62closesodoo/odoo#153100
Signed-off-by: Alexandre Kühn (aku) <aku@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#153460
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Versions
--------
- 17.0
- 17.1
- master
Steps
-----
1. Go to Settings / Manage Languages;
2. select your current language;
3. set First Day of Week to something other than Sunday;
4. go to Time Off app.
Issue
-----
Weeks in year overview still start on a Sunday.
Cause
-----
Commit 52dae7a2f0 hardcoded `firstDay` to
Sunday for the `hr_holidays` module. This was a workaround to some
issues with `fullcalendar`'s week number calculations.
Solution
--------
Remove the hardcoded `firstDay`, and add a custom week numbering
function to be used on week, month, and year calendar views for
consistent numbering that allows for different first days of the week.
The function returns the ISO week number of the Monday nearest to the
configured first day of the week, i.e. the following Monday when first
day is set to Friday, Saturday or Sunday, the previous Monday if first
day is set to Tuesday, Wednesday or Thursday.
There were 3 main considerations for deciding a week numbering method:
1. no exisiting setting for users to decide on a method;
2. the ability to pick a first day of the week independent of locale;
3. the version of `luxon` used being unable to factor in locale.
Addendum
--------
This commit doesn't fix the issue with group-by week numbering in list
view. These stem from `babel`'s inconsistent locale defaults and
inability to take user-configured first day of the week into account.
opw-3668175
closesodoo/odoo#148623
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
The goal of this commit is to improve the comment in the `loadImageInfo`
method.
We decided to retarget [1] to master for a potential merge over there,
although it might just get cancelled entirely. We leave the small
regression in stable: not being possible to customize an image (filter,
optimization, etc) of an image-added-by-url when the URL is actually...
an image in a static folder of your own instance's website. This worked
in the past but this is kinda a weird use case which has alternatives.
Fixing it in stable would be choosing between two possibilities:
- Checking that the URL is actually a "local" URL -> this is exactly
what we cannot do anymore if we want another bug fix to remain: the
updated comment explains why.
- Also supporting customizing images added by URL for "external" URL
-> this is too risky in stable, that is why [1] will be considered in
master only, although it will not be strictly necessary over there
since the improvements made with [2].
[1]: https://github.com/odoo/odoo/pull/151858
[2]: https://github.com/odoo/odoo/commit/943944dd249c15de870d6800d89e48d54a422e5aclosesodoo/odoo#153716
X-original-commit: 9d827cc22245a6706d5b6b94ac3c30a3d8cb238b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Add method '_get_discount_product' to allow to override the product used
by the sale_order_discount wizard.
closesodoo/odoo#153652
Signed-off-by: Jérémy Kersten <jke@odoo.com>
When a user is modified to grant access to new groups, user is
auto-enrolled to all slide courses that have a auto-enroll policy for
any of the new groups.
However, that auto-enrolling process was not working correctly due to
how values to be written to the user are coming. In order to know what
are the actual new groups, values need to be pre-processed, which was
not being done.
This commit fixes the above issue by pre-processing written values
before extracting new groups.
closesodoo/odoo#153634
X-original-commit: e27be4a81c304c2d749b4417d2184cfed07eddf3
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Rules always have a pricelist, so we can avoid an
useless database query when we are computing the
prices without any pricelist.
Also makes sure that the modified context used
for the pricelist items search is not propagated
by enforcing the same context in the returned
rules.
closesodoo/odoo#153624
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, to render the table, the project task list
view computed the list of selected records once for each cell,
and then iterated over that selection to check whether selected
tasks were all associated with the same project (to set the
stage_id field readonly if not). However, computing the selection
requires to iterate over all records, so the rendering was O(n^2).
As a consequence, the rendering of (not so) large tables was very
slow (~1s for 80 records).
With this commit, we compute only once for the whole table whether
the selection contains records from different projects.
closesodoo/odoo#153611
Signed-off-by: Géry Debongnie <ged@odoo.com>
How to reproduce the error:
1. Go to Contacts.
2. Select a Contact of Type Company:
Find and select a contact that is a company type and to which a
price list has already been set up previously.
In case no price list has been set previously, set the price list
and save the contact.
3. Edit the contact and modify the address state without the need to
save the changes.
4. View the PriceList:
After changing the province, look at the price list field. You can
verify that the price list has become blank immediately after making
the change in state, without the need to save the changes.
Current behaviour: the price list is deleted when the state of the address is changed.
Expected behaviour: keep the previously set price list.
Explanation:
The code was incorrectly using "p.id" instead of "p._origin.id" to get
the contact ID. This resulted in a non-existent key being retrieved and
caused the loss of the price list in the contact when changing the province.
The fix adjusts the code to correctly use "p._origin.id", ensuring correct
retrieval of the ID and avoiding unwanted changes to the price list.
Example of data obtained by debugging:
- Edited user: Deco Addict
- Data obtained in "res": res {53: product.pricelist(1,)}
- Data retrieved in "p.id": (p.id) > NewId_53
- Data retrieved at "p._origin.id": (p._origin.id) > 53
TT47536
closesodoo/odoo#153326
X-original-commit: 570715ecc6c9b105a2edaed23a68f557e5cf1987
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
While fixing a non deterministic test failing
on nightly l10n builds, slight incoherences between
sale & website_sale tax computation have been noticed
in the computation of the contextual price (used in
some snippets).
This commit fixes the test, making sure it doesn't fail on
l10n builds, but also uses the same tax util in website_sale
than in sale, to make sure the displayed amounts are coherent
(and supposedly correct).
runbot error: 52831 (& a bunch of others)
closesodoo/odoo#153299
X-original-commit: 91f9057c73810c34a4b0b85a60c84bb1c482efa4
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Specification:
This commit target the scenario when image is in selection and the toolbar
displays AI option for it, which made no sense as the generated response
will replace the image.
After this commit:
The toolbar has been updated to show AI option only for text based scenario
task-3733320
closesodoo/odoo#153190
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Current behavior:
When printing the bill before the order has been paid, the QRCode to get
the invoice shouldn't be shown.
Steps to reproduce:
- Activate the option "Show QR Code" in the POS settings
- Create a new order
- Add some products
- Click on "Bill" button
- The QRCode is shown
opw-3703720
closesodoo/odoo#152918
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
How to reproduce:
- Install crm with demo data
- Open the crm app
- From the menu "Configuration -> Activity Plans", create a plan
- Open a lead
- Schedule the plan just created for the lead
The log message in the chatter display due date in the wrong format:
Year(4)-month(2)-day(2) instead of the user date format (if your date format is
that one, please change it for testing).
This fixes the problem by displaying the date in the user format.
Task-3639909
closesodoo/odoo#152217
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit's purpose is to fix the re apparition of personnal stage on
the todo app when personnal stages are deleted one after the other.
Step to reproduce:
-login as Marc demo
-open todo
-delete any personnal stage without any todo in it
-delete any personnal stage with at least one todo in it
The personnal stage deleted first is now present again in the kanban
view. Note that it is only a frontend bug. The record has been correctly
removed from the db, and any action with it will trigger a cache miss
exception and reloading the view completly will removed those ghost
stages definitly.
Source of the problem:
The problem is that the deletion is only reloading the view completly
when a record with child data is removed. More precisly, the
_deleteGroup function of the dynamic list triggers an rpc call to update
the config of the component only when a record with child data is
deleted, and that data need to be switched to another record, while when
it is an empty record, the record is simply removed from the group
field of the list. The issue is that there is thus a mismatch between
the group in the list.config.groups and the list.group. And when the
config is updated, only the list.config.groups is used to update the
config, meaning it potentially still contains element that were already
deleted.
Solution:
Doing a check up on the list.group to ensure that any deleted element is
also removed from the config when an update is triggered.
Note: I dont why Mitchel admin did not trigger the bug. Code wise, it
should happends no matter the access right of the connectedd user.
Version affected:
17.0+
task - 3553101
https://www.odoo.com/web#id=3553101&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=formclosesodoo/odoo#142536
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit fixes an unconsistent forestack icon within the `sale_stock`
module.
Prior to this commit, the forecast icon was using a `text-primary` class,
making it unconsistent regarding the other forecast icons.
We also add a missing `cursor-pointer` class to fix the improve the hover
state and the visual feedback of the link.
task-3582145
closesodoo/odoo#153618
X-original-commit: e3c7273dbd8c9945bd5b983e864bbb0530114df4
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
In tax report, ve38 line should display the tax
excluded amount, not the tax amount.
opw-3609402
closesodoo/odoo#153558
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
In case of tax update, tags were remaining even if user
deleted them.
This is because we don't clear the repartition lines before
reassign them in `_pre_reload_data()`
Part-of: odoo/odoo#153558
Steps to reproduce:
- Create a child company.
- In the child company, create a new sales journal.
- Create and confirm an invoice using this new journal.
- Attempt to create a credit note from that invoice.
In this scenario, you would encounter an error.
Cause:
The `AccountMoveReversal` wizard is currently setting its company to the
root company of the moves, which in this case is the parent company.
However, its journal is set to the one created in the child company.
This mismatch causes an error due to company inconsistency.
Fix:
The `company_id` of `AccountMoveReversal` will now be assigned to the
company of the moves, rather than the root company. To ensure this works
correctly, we also added a check to guarantee that all moves being
reversed are from the same company.
Note:
This fix also resolves an issue where a traceback occurred if two
invoices were created (one in the child company and another in the
parent company) and an attempt was made to reverse both simultaneously.
opw-3640719
closesodoo/odoo#153396
X-original-commit: cd62e3fcaab3e71e606607308cace739bc480c4f
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
**Current behavior:**
Trying to create an opportunity as a portal user and leaving
any of the fields empty will cause an unnecessary exception
dialog to flash on screen.
**Expected behavior:**
Submitting the form with empty required fields will just prompt
the user to add values to all fields.
**Steps to reproduce:**
1. In the Contacts application, go to a portal user and in the
Partner Assignment notebook tab, give them a partner level
2. In the CRM app, create a new lead and assign the portal user
who was granted the partner level as the customer
3. Login as the portal user, and convert the lead in My Leads
to an opportunity
4. Go to the my/opportunities website menu
3. Select 'Create Opportunity' in the top right and leave
any/all of the fields empty then select 'Confirm'
**Cause of the issue:**
The catch block in the _buttonExec() function is rejecting its
Promise when it catches anything aside from an RPCError.
**Fix:**
Only reject the Promise when the catch block encounters an
actual Error, preventing dialog window popups when non-critical
exceptions (non-Errors) are thrown.
opw-3703238
closesodoo/odoo#151982
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Product template "property_account_expense_id" and "property_account_creditor_price_difference" fields must stay editable in cases even if not "can be puchased".
Since it being readonly is trivial, better leave it writeable instead of implementing cross module readonly logic.
closesodoo/odoo#150601
Task: 3695677
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Issue:
When the notification webhook is enabled for Adyen, sometimes the response back causes an SQL concurrent update. Odoo then creates a retry towards Adyen, charging the customer card several times. Both the notification webhook and the payment controller are hit, and try updatingthe same row simultaneously, which causes this behavior.
Steps to reproduce:
This bug is not reproducible due to a connection issue for the Adyen test account. However, if the payment request would implement idempotency we could prevent billing the customer on the same request if the request reaches this collision and is retried multiple times.
Description
A first payment request is sent to Adyen. The card is charged and Adyen answers that all went as expected.
We try to process the payment, but a concurrent access error occurs.
A retry is done.
A payment request is sent again to Adyen, The card is charged AGAIN and Adyen answers that all went as expected.
We try to process the payment, but a concurrent access error occurs.
For each retry, the request is sent and the card is charged.
If the first retry succeeds, then Odoo can finish the process. There will be only 1 payment transaction on Odoo's side
(others have been rollbacked) but there will be 3 on Adyen's side and the card will be charged 3 times.
This PR fixes this behaviour by adding the idempotency key to the headers with the hash of the transaction
reference and the database UUID, we prevent duplicate payments to happen.
OPW-3584300
closesodoo/odoo#153734
X-original-commit: cf035accd8fd633de84c86e2bf426c900c865b9f
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Mehdi Rachico (mera) <mera@odoo.com>
In b69917e[1] the cron implementation was changed to unlink old visitors in
batches of 1000 records. This was meant to deal with memory/timeout
errors when dealing with large amounts of records.
However it still searches for records with no limit, which in high
record count scenarios and based on instance resources may still
generate memory/timeout errors.
Technically it could be considered "fine" for the cron to timeout since
every batch is committed, so previously unlinked records are not rolled
back and the cron should eventually delete them all.
However there are some edge cases where memory/time out errors would not
be fine, like the cron failing during the first batch, which means no
unlink operations would be committed to the database.
Errors that are "fine" also generate noise and leave administrators
wondering which errors they should ignore and which they should not. It
also alarms non-technical customers since after all, they are seeing
a reported error.
Therefore the search limit and batch size have been added as arguments
to the cron. This is completely opt-in since they have the previous
values as their defaults. This makes it easy to customize and tune the
performance of the job accordingly if required.
[1] https://github.com/odoo/odoo/commit/b69917ec0e508f8354d831525c5c48ee79b5967a
X-original-commit: e8a4b1f6a239753f66aa827e8e0d67ca4270dba3
Part-of: odoo/odoo#153707
The onExternalClick custom hook keeps a reference to elements that may
no longer be in the DOM, this can cause entire sections of the DOM that
are no longer needed to be kept in memory, and can also retain the
associated Owl components and their data.
To solve this, we set the downTarget and upTarget to null after calling
the callback. In practice they are no longer used in the code but we are
keeping it for stable compatibility.
closesodoo/odoo#153654
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, when exporting its state so that it could be restored later,
the relational model would export its config. The problem is that
because this config is a reactive object, it keeps a reference to the
components that may need to be notified by that reactive object. This
exported config was then stored on the next controller, which would be
retained by the next config, etc.
This commit fixes that by exporting a raw version of the config.
Part-of: odoo/odoo#153654
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.
`.id`
task-3735923
closesodoo/odoo#153475
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
In previous versions the max size of a domain was bounded by psycopg
memory limits. With the new SQL formatting mechanism the limit is bound
by the maximum recursion limit in Python side. The purpose of this patch
is to restore previous behavior.
In 16.0:
```
>>> def make_dom(N):
... return [*('|' for x in range(N-1)), *(('login', '=', 'admin') for x in range(N))]
...
>>> u.search(make_dom(9984))
res.users(2,)
>>> u.search(make_dom(9985))
Traceback (most recent call last):
File "<input>", line 1, in <module>
u.search(make_dom(9985))
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 1520, in search
return res if count else self.browse(res)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5140, in browse
if not ids:
File "/home/odoo/src/odoo/16.0/odoo/tools/query.py", line 217, in __bool__
return bool(self._result)
File "/home/odoo/src/odoo/16.0/odoo/tools/func.py", line 28, in __get__
value = self.fget(obj)
File "/home/odoo/src/odoo/16.0/odoo/tools/query.py", line 210, in _result
self._cr.execute(query_str, params)
File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 321, in execute
res = self._obj.execute(query, params)
psycopg2.errors.SyntaxError: memory exhausted at or near ""login""
LINE 1: ...((("res_users"."login" = 'admin') OR ("res_users"."login" = ...
```
in 17.0 without this patch
```
>>> u.search(make_dom(1480))
res.users(2,)
>>> u.search(make_dom(1481))
<shortened output ...>
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 86, in <genexpr>
if isinstance(child, SQL):
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 86, in <genexpr>
if isinstance(child, SQL):
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 86, in <genexpr>
if isinstance(child, SQL):
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
RecursionError: maximum recursion depth exceeded
```
This issue was observed in upgrades in multiple instances. Example: MRP
produces an OR domain with 2K terms for warehouse sub-locations that
fail.
closesodoo/odoo#153394
Signed-off-by: Raphael Collet <rco@odoo.com>
This PR fixes 2 issues with discuss navigation:
1. Broken backwards navigation when going back and forth from the live
chat session history.
2. Broken backwards navigation when trying to access the same thread
than the current one.
Steps to reproduce 1:
- Open the command palette
- Go to the live chat session history view
- Click on one of your channels
- History back => leads to the session history view
- History forward => leads to discuss
- History back => stays on discuss, history is broken
This occurs because the active id is not passed in the action context
when navigating backwards which leads to the URL being pushed again in
history (URL without active id is different). The active id should be
put in the context when available.
Steps to reproduce 2:
- Go to discuss
- Click on the active thread
- History back => stuck on discuss, cannot navigate backwards anymore.
We should not push in history when accessing the same thread than the
current one.
task-3422516
closesodoo/odoo#153094
X-original-commit: 029b79ad7dc28aab83289e7c3ebd4cc0dcc5d609
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
The commit odoo/odoo@a72007508a fixed the dialog for the import of
a module, but broke the (shared) view for the dialog of the installation
of an industry. This commit fixes both dialog views.
closesodoo/odoo#153013
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Issue:
- When checking future accruals in the Time Off dashboard, the Balance
view doesn't update correctly. For example, with an accrual plan of 1h
per month starting on 30/11/23, the balance in December should show 2h
but incorrectly shows only 1.12h.
-This happens because the '_get_future_leaves_on' method always returns
values in days, ignoring the 'type_request_unit' of the allocation.
Steps to Reproduce:
- In the time-off app set an accrual plan: 1h per month, accrued on the
first day of the month.
- add a new allocation to Mitchell Admin with that plan
- Notice that In the dashboard the balance is 1h
- Change the date to next month, new amount is 1.12h, in stead of 2
Solution:
- Added a check to correctly calculate future accruals in hours when
type_request_unit is 'hour', ensuring accurate hour-based balances.
opw-3685077
closesodoo/odoo#152870
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Since the introduction of the Embed Code snippet with [1], in case some
content was created dynamically through a `<script>` tag, it would be
duplicated upon editing the snippet again after it had been displayed a
1st time. This is because each time you open the snippet's ace editor,
the current state of the snippet (including dynamically created
elements) is saved in the view.
This commit removes the `<script>`s inside embed code snippets from the
view in edit mode, and then saves them on the server upon save.
We also take the opportunity to add a message in edit mode if the
snippet doesn't display anything (e.g. if it only contains a script tag,
or an empty element), so that it is easily focusable to edit its
content.
Finally, we add a message upon editing an embed code snippet to inform
the user that they should not use it unless they know what they're doing
as well as tell them they may inject code in the `<head>` or `<body>`
elements through the Theme panel.
Note: this fix is only valid for code injected inside the embed code
snippet. For code injected outside of the snippet, we have no way of
controlling / sanitizing the DOM after the fact.
Steps to reproduce:
1. Drag and drop an Embed Code Snippet
2. Copy the following code:
```
<script>
document.addEventListener('DOMContentLoaded', function () {
const alertEl = document.createElement('div');
alertEl.classList.add('alert', 'alert-primary');
alertEl.textContent = "Hello";
document.getElementById('some-stuff').appendChild(alertEl);
});
</script>
<div id="some-stuff"></div>
```
3. Save and exit the editor. The injected div should appear.
4. Go back to the editor, click to edit the snippet and either save or
discard.
5. Exit the editor
=> The div is duplicated.
[1]: https://github.com/odoo/odoo/commit/2cc481d1a62202ade4c1ca8f846c962f9f2cc34d
opw-3513760
closesodoo/odoo#152502
X-original-commit: e6fe14dc90af6782693fd5e9dca6f18ecfe7c89a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue:
------
Since this commit[^1], a user who is not in the `Administration/Access Rights`
group cannot modify certain fields available to him on his user profile
(`livechat_username` and `livechat_lang_ids`).
Solution:
---------
As it is possible for a user to write to these fields, it is necessary
to put them in `SELF_READABLE_FIELDS` in order to obtain sudo rights
when writing if the environment user corresponds to the user
to whom we want to write the new values.
opw-3717266
[^1]: 78f6b83b34closesodoo/odoo#152425
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Most (if not all) dashboards have monetary amounts. They are formatted
with the main company currency format.
Before this commit, a RPC was made to fetch the company currency.
With this commit, the dashboard is loaded with the currency.
It saves one network request and a full spreadsheet evaluation (which would
have occured after the request is done)
closesodoo/odoo#151725
Task: 3709466
Related: odoo/enterprise#55415
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Pivot/list monetary fields needs the company currency to display
the value in the said currency format.
Until now, a RPC was made to fetch the currency.
However, since odoo/o-spreadsheet@8710839 and odoo/enterprise@8c0a785
the currency format is already in the model config.
There's no need for the RPC.
This saves one network request and one full spreadsheet evaluation (which
would have occured after the request is done)
Note: see next commit for dashboards.
Part-of: odoo/odoo#151725
- create a from/to date filter with let's say "my filter"
as its title.
- in the spreadsheet, `=ODOO.FILTER.VALUE("my filter")`
=> the function doesn't return anything
closesodoo/odoo#146213
Task: 3584650
Related: odoo/enterprise#52871
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
The implementation to generate a sheet with the active filters
is (almost) duplicated for the Excel export and the sharing.
The next commit makes it more complex and in the goal of avoiding
to duplicate the changes, this commit factorizes the implementation
Task: 3584650
Part-of: odoo/odoo#146213
Issue: When purchasing tickets for an event, if the quantity of tickets
is reduced directly from the cart, payment can be processed for the
reduced number of tickets while the excess registrations remain
incorrectly open in the database.
Steps to Reproduce:
1 Install Events Online Ticketing.
2 Create or select an event with open registrations.
3 Add 3 registrations to your cart and proceed to checkout.
4 In the payment process, go to 'Review Order' and reduce the quantity
of tickets.
5 Complete the checkout and payment.
6 Upon inspecting the database for the same event, you'll notice an
inconsistency: the number of attendees is higher than it should be.
Solution:
This issue arises from the implementation of
`_compute_registration_status`, which only considers the sale order line
and marks registrations as cancelled only if the entire order line is
cancelled. This means either all 3 registrations are cancelled, or none.
The solution introduced here addresses this by checking for
registrations already marked as cancelled and incorporating them into
the cancellation logic, ensuring accurate tracking of active and
cancelled registrations.
opw-3653452
closesodoo/odoo#150463
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
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>
abd-msyukyu-odoo