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>
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>
Levi Siuzdak (sile)