In this commit
=============================================
Before if all the lines were of service the error was displayed in a banner
after error in response was received, but now before sending request the lines
are checked if at least one line is of product and error is raised.
Issue in this: https://github.com/odoo/odoo/pull/153522/commits/c81595db6a7a135a3289751a9b881b2f947bc6d2closesodoo/odoo#154290
X-original-commit: 831d318a2993e8c4ac92739bf3604ad04dec924f
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Surabhi Varma (suva) <suva@odoo.com>
Steps to reproduce:
1- Install Sales module
2- Activate developer mode
3- Navigate to any storable product
4- Click on 'Replenish'
5- Click on 'developer bug' and Choose 'Set Defaults'
6- Choose 'Scheduled Date' from the 'Default' dropdown menu and Save
Current behavior before PR:
When trying to set a default value for scheduled date in 'Replenish' for a product it will display an error for 'Invalid type' this is happening because when converting the string value to a datetime value it does not handle iso format date and this is the format that gets passed from the UI.
Desired behavior after PR is merged:
It is handled now from the UI side that the format that is been sent is the server valid format of datetime.
opw-3692472
closesodoo/odoo#154209
X-original-commit: 6dc46639935fdc175b2d094b58ef4e66c68466b0
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Since 16.3, opening the web client on the Odoo backends results in two
subscribe events being sent through the bus websocket.
Discuss listens to the thread changes to know when the subscription
should be refreshed. In order to do so, the last subscription that was
made is kept. This issue is that this subscription is empty in the
first place so the first evaluation always considers the subscription
should be made.
In order to fix this issue, this PR refine the condition to determine
if the subscription should be renewed:
- The last subscription is different from the last one
- The user joined a channel after the bus initialization
- The user left a channel after the bus initialization
In order to test those scenario in a reliable way, this PR also
backports odoo#147455
closesodoo/odoo#154170
X-original-commit: 109b45f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Description:
When searching with a domain that contains a relational field whos
comodel is `res.users`, with a *pathological* domain of `not ilike`
`'some_string'`, the ORM will call a `_name_search` on `res.users`
with no limit to resolve the leaf when calling `_where_calc`.
The current implementation in the `web` module overrides the
`_name_search` to implement a spec to propose the current user as a
first suggestion, but to do that it first execute the query
(the list conversion), and then manipulates the list of ids to insert
the current user first. (1c2ce8c213)
On large databases with many `res.users`, where the condition matches all
users besides 1, this is a probably Seq.Scan on the `res_users`
table. Then this gigantic list of `ids` will be injected by the ORM
into the main query to satisfy the original domain. This incurs not
only bandwidth costs, but also usually leads to bad plans, ending up
most likely into a Seq.Scan on the original table.
The worse of it, in the case of a `web_search_read`, there is a
`search_count`, so this whole fiasco is repeated once more.
The nail in the coffin, is that the result isn't even needed, when
resolving a comodel's `_name_search`, we care about the subset, the
internal order is irrelevant.
Solution:
The ORM calls the `_name_search` without a limit, while in general the
`name_search` is called with a limit from the front-end, therefor we
can use it as a discriminant -> If no limit, don't suggest `uid` first.
Affected versions:
saas-16.3 -> master (saas-17.2)
Reference:
task-3610657
closesodoo/odoo#154149
X-original-commit: 83aa46a4ab88c0226b1aa1dc36671d3208a0835a
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Prior to this commit, automatic printing was only functional when
a printer was configured with the Point of Sale. It did not support web
printing. This commit rectifies this issue, allowing automatic printing
to work seamlessly with or without a physical printer setup, supporting
web printing.
opw-3706400
closesodoo/odoo#154066
Signed-off-by: Joseph Caburnay (jcb) <jcb@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#153464
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
Current behavior:
When you make an order in the PoS with different lots for the same
product, the lots are not correctly selected in the picking. And only
one lot is affected by the order.
Steps to reproduce:
- Create a product with tracking by lot, and 2 lots with some quantity
- Create a PoS order with 2 lines of the same product, and select a
different lot for each line
- Validate the order
- Close the PoS session
- Check the picking, and the lot quantities
Note:
This partly revert this part of commit :
https://github.com/odoo/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81#diff-0ef4eb66998f308afe5f09748bc2af04ad79e9647507c25fe9007e03a79a1249L265-L303
And also make sure that the original created line quantity is set to 0
so that the each lot has a line, and the total quantity is correct.
opw-3621363
closesodoo/odoo#148517
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
1. Make sure to return archived users in partner format.
2. Remove the condition to check for archived users in suggestion code.
The condition made no sense since the refactoring (that's the opposite
of what we want, and it didn't compare the partner records correctly).
The feature is broken since https://github.com/odoo/odoo/pull/133065/
because it "fixed" the way records are compared. Making the condition we
don't want in the first place actually working and excluding OdooBot
(instead of allowing it).
3. Since archived partners are displayed anyway since the refactoring,
and nobody complained, let's consider it a wanted feature.
Archived partners are given lowest priority and moved to the bottom.
task-3747277
closesodoo/odoo#154078
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- Open any course.
- Open full-screen window.
- Click on exit fullscreen
- The progress bar color is mixed up with the background.
Issue:
In Odoo primary color is changed from v17.0
Solution:
Applied bg-info class to progress bar for better visibility.
Task-3721175
closesodoo/odoo#152815
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In the current system, the order widget experienced undesired updates to all order lines when a new product with the same attribute was added. Our recent changes address this issue, ensuring that existing attribute values remain unaffected by the addition of new ones.
Moreover, we've refined the display of attribute information. If an attribute is designated as "never," it will now be incorporated into the order line note. Conversely, attributes with different settings will continue to be displayed in their usual format.
closesodoo/odoo#152213
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Before this commit:
-On inserting icon in note, it replaces another icon.It occurs because
`isEmpty(block)` returns true, when block element was font-awesome, which
causes the code in `insert` method to remove current node, resulting in removal
of previous icon.
After this commit:
-Now icon is added without replacing the another icon.
task-3482264
closesodoo/odoo#152929
X-original-commit: 9a9487752131fddaf9ff163cb22226b256cef81d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Currently an empty section is not considered empty text.
As the web editor sometimes uses them, it is relevant to consider
them when asking whether some html will appear empty.
Currently, even completely removing the website description of an
exhibitor in website_event_exhibitor from the backend does not make
the 'missing description' tooltip appear in the front-end
task-3607615
closesodoo/odoo#154097
X-original-commit: 7dc376d4d2d2b4000de0da7573c30e4508f32318
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
Steps to reproduce
------------------
* install `l10n_ch_reports`
* switch to a Swiss company
* enable "QR Codes" in Settings > Accounting > Customer Payments
* create and confirm two invoices for a Swiss partner
* on the invoice list view, select and attempt to print the two invoices
at once
You should be met with traceback.
opw-3697569
closesodoo/odoo#154063
X-original-commit: b6cb6b3ecd80d8c919790cc3178dfcb62f6f49fb
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
**Issue Description**:
From versions 16.3 to the master branch, a sub-task should never be assigned to a project automatically. However, when accessing `Sub-tasks` through the smart button and creating a new one, the context pass variable such as `'default_project_id': 4`. This leads to the sub-task being created with an assigned project immediately.
**Steps to Reproduce**:
1. Open `Project` app.
2. Enter any project, then navigate to any task.
3. Within the task, go to `sub-task` tab.
4. At the top center of the page, click on 'Sub-task' smart button.
5. Then, create a new sub-task using the 'New' button.
6. You will observe that the sub-task is immediately assigned to a project, which should not happen.
**Proposed Solution**:
By removing the passing of the default_project_id variable from the context when open a sub-task action, we ensure that sub-tasks are not automatically assigned to a project, as intended.
opw-3708537
closesodoo/odoo#154101
X-original-commit: c45ac4c9584f961ea0cdedffdf2b4bbe9058e8d9
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Ilya Rudy (ilru) <ilru@odoo.com>
Steps to reproduce:
1- Install Members module while Accounting is uninstalled
Current behavior before PR:
When you install Members module without having Accounting module you will not be able to access Members module as it will be hidden on the dashboard. This happens because of the access rights that the Member module has as it is having the access right group of the Accounting module 'group_account_user'. This issue happened after this commit https://github.com/odoo/odoo/commit/f6c60e497520d7916937f4a2a57ed3f8c2e1049b#diff-65a587634b23c60ecc8eea20881920a50eddbc569aa5d0381705b7405e918e2e
Desired behavior after PR is merged:
Now the Members module has the access right group of Invoicing module 'group_account_invoice' which is the only dependency module that Members need. So it will be visible and accessible from the dashboard once installed
opw-3627010
closesodoo/odoo#154070
X-original-commit: d0bd175e10f72649bcd310d6d5b068dc6bfd2b5f
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
When installing the Odoo Debian package on Bookworm, under certain
conditions, the following bug may arise:
`Warn: Can't find .pfb for face 'Times-Roman'`
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059326
As this bug is not yet fixed on the Debian side, this commit is a
workaround.
closesodoo/odoo#154017
X-original-commit: 70e192137e9b603c502aea878313cd7611fe0337
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Steps to reproduce:
- Install `event_crm` module
- Create an Event with a company
- Go to `Events > Configuration > Event Lead Rules`
- Create a new rule and set no company
- Try to set the event created above for Event field
Issue:
Event created not displayed as possible value for the Event field.
Cause:
Because we have `check_company=True` set on `event_id` field, the
field will be filtered based on the `company_id` field, and since no
company is set on the rule, events with company will not be listed.
Commit that introduced the issue: https://github.com/odoo/odoo/commit/0479b2b59466ae1d6d74165345aa3a7dc5de24ed
Solution:
Revert to the previous behavior (remove `check_company=True` from
`event_id` field and use a domain instead).
opw-3715864
closesodoo/odoo#154009
X-original-commit: 13cb20dafb6dd473fe71b605a2adf70fa0ac368e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- Switch to a language where removal strategy name is translated
(FR in 17.0)
- Edit product category and set a translated removal strategy
- Update on hand quantity
Bug:
User error removal strategy not implemented
the removal strategy name is used in the code to identify them
when changing the name through translation it is not recognized anymore
Fix:
use the untranslated term when checking the strategy type
opw-3697462
closesodoo/odoo#153970
X-original-commit: 210f0d1c56dab45b2a00f86e1c7d836f558e6feb
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Desired behavior after PR is merged:
Enhancing the job posting with an XML tag for the title of the position so it can be used for the google rich search.
opw-3713519
closesodoo/odoo#153682
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Since PR #137969, the `save` button is no longer available in schedule activity
wizard.
This PR makes `schedule` button available for call activities like other
activities (except meeting), so user can create a call activity without going to
calendar view.
Also, we have to consider `has_error` in creating activity so if there is an
error, user couldn't access to `schedule` button. This field is correctly placed
in `mail.mail_activity_schedule_view_form` view but not in the inherited view
in `calendar`.
task-3668732
closesodoo/odoo#152893
Signed-off-by: Maryam Kia (maki) <maki@odoo.com>
Steps to reproduce
==================
- Install account_accountant
- Go to settings
- Enable Budget Management
- Go to Accounting > Reporting > Management > Budgets Analysis
- Switch to the graph view
- Change the measure to "Planned amount" and then back to
"Practical amount"
=> The practical_amount measure is undefined,
The theoritical_amount measure is missing.
Cause of the issue
==================
The view is defined as follows:
```xml
<graph string="Budget Lines" sample="1">
<field name="crossovered_budget_id" type="row"/>
<field name="planned_amount" type="measure" string="Planned amount"/>
<field name="theoritical_amount" type="measure" string="Theoretical amount"/>
<field name="practical_amount" type="measure" string="Practical amount"/>
</graph>
```
The theoritical_amount and practical_amount are non stored fields and
thus are skipped inside `computeReportMeasures` unless they are passed
in `activeMeasures | additionalMeasures`. [0]
When parsing the graph view, the last field of type measure is
passed to the graph model and is the one that will be used initially. [1]
This is why the practical_amount is initially defined.
Solution
========
We simply need to keep track of fields of type measure.
This was the case in 14.0 but got lost in the conversion.
---
[0]: https://github.com/odoo/odoo/blob/e7a9ebec3176c37485643fcda2381e489a1df86f/addons/web/static/src/views/helpers/utils.js#L49-L60
[1]: https://github.com/odoo/odoo/blob/0fb64bef16914937cf4a1d1618fb58ade6d16f14/addons/web/static/src/views/graph/graph_arch_parser.js#L63
opw-3713613
closesodoo/odoo#153967
X-original-commit: 76178cd61ba10ff29b24183edb550c54b319a230
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
This fixes a bug where trying to set the default name value
of an expense report when created from the expense tree view
would traceback.
Step to reproduce:
- Create 2+ new expenses having the same payment_mode
(E.G. 'own_account')
- Clear the date field of an expense so at least one of the expense
has a date and one has no date
- Press the 'Create Report' button on the expense tree view
Current behaviour:
Traceback due to bool > Date comparison
Expected behaviour:
We fallback to a default name when two sheets are created.
We do not set a name when only one shert is created.
task-3725176
closesodoo/odoo#153943
X-original-commit: ddb3b825a7bec28975052f858ea1512a7cf16f08
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Steps to reproduce the bugs:
- Install the e-commerce on your website.
- Go to the "/shop" page.
- Click on "Edit" to enter edit mode.
- Click on the "Customize" tab.
- Choose "Cards" for the "Style" option.
- Enable the "Product Description" toggle.
- Click on the "Theme" tab.
- Click on the 4th color of the theme colors and choose "black".
- Save the page to exit edit mode.
- Bug 1: The product description and the price in the product cards are
not visible.
- Bug 2: The scrollbar below the category buttons has the same color as
its background.
- Click on the "Mobile Preview" button in the backend navbar.
- Click on the "Filters" button on the page to show the offcanvas.
- Bug 3: The text color in the offcanvas is not visible and the
background color of the inputs is the "body" background color instead of
the "offcanvas" background color.
opw-3570774
closesodoo/odoo#153930
X-original-commit: add2b9273e90e3940ee52eee4ff42afa46c18a20
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: website_sale
Steps to reproduce the first bug (popover):
- Install the e-commerce on your website.
- Go to the "Customizable Desk" product page.
- Click on "Edit" to go in edit mode.
- Click on the "Theme" tab.
- Click on the 4th color of the theme colors and choose "black".
- Save the page to leave edit mode.
- Click on the "Add to cart" button.
- Hover over the cart in the navbar to make the popover appear.
- Bug: All the popover texts are not visible because they are white and
the background is white.
Steps to reproduce the second bug (extra price badge):
- Install the e-commerce on your website.
- Go to the "Customizable Desk" product page.
- Click on "Edit" to go in edit mode.
- Click on the "Theme" tab.
- Click on the 4th color of the theme colors and choose "black".
- Save the page to leave edit mode.
- Bug: The text of the "extra price" badge is not visible because both
text and background are white.
These two issues existed because the text color of those elements
depended on the body's background color. With this commit, the text
color for those elements is now determined by their respective
backgrounds.
This commit is a follow-up to this commit [1]. We also add the handling
of the text-muted color to ensure it remains visible if a modal has a
dark background while the body background color is light. Before this
commit, we only handled the opposite case (dark body and light modal).
This commit also fixes the text color of the button in a file input of a
form when the background color of the <body> is dark. Similar to the
other elements fixed in this commit, the text color of this button could
be invisible because it was the same color as its background.
[1]: https://github.com/odoo/odoo/commit/308b91c58b00300fd8dc52b9b4e2f7d1ab31f7b7
opw-3570774
X-original-commit: 0c2806576e85106d06f4275c9204e664f69793d8
Part-of: odoo/odoo#153930
Reproduction:
1. Install Sales, Email Marketing
2. Go to Email template by searching
3. Click the Sales: Send Quotation template and make a duplicate
4. Add empty lines in the template, till it almost reaches the end of
the page
5. Use slash command to add a Dynamic holder, and it’ll be positioned
below the page
Fix: compute the position by consider the height/width of the popover to
make sure it’ll be always in the page
opw-3373403
task-3442559
closesodoo/odoo#153969
X-original-commit: 583ef2441e6aa9a6d13f50991a0d1d3a54c31db1
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
In this commit
=============================================
Before if all the lines were of service the error was displayed in a banner
after error in response was received, but now before sending request the lines
are checked if at least one line is of product and error is raised.
closesodoo/odoo#153816
X-original-commit: 251ee180ba0342f6a8c84d0a3ee93156a1cb06e0
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Surabhi Varma (suva) <suva@odoo.com>
When invoicing public administrations, they expect the facturae
electronic invoice to contain the optional `<PaymentDetails>` node that
contains e.g. the bank account number to which they need to issue the
payment. We didn't provide these details.
This commit adds the necessary `<Installment>` nodes in the
`<PaymentDetails>` node for each installment in Odoo according to the
payment terms of the invoice.
Since we are fixing this in stable, we only add the payment details for
inbound payments and fix the `<PaymentMeans>` to `04` (Credit Transfer).
We also removed the stripping of whitespace for the signature, since it
turned out not necessary after introduced in [1]
[1] e5d69a73e2e781d00f67c0590a8fc13b09a06ebf
task-3734341
closesodoo/odoo#153931
X-original-commit: 7f88e41fb6b723c8d240344a50a5b4b8b4aa3f2f
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Steps to reproduce:
-Create a SO and sell a prepaid service in days
-Set the timesheeting to days/half-days
-Add a timesheet line on the task of the SO
-Go to database/my/timesheets and look for the timesheets
of the SO
-> The days ordered are wrong
Before PR:
If you confirm the SO with the timesheeted SOL's uom as
days and your timesheeting is made in days, the view will
convert the amount of days as if it were hours, showing wrong
values
After PR:
Made the report more robust, now converting whatever unit the
SOL has to either hours or days depending on the timesheet
setting
opw-3643988
closesodoo/odoo#153898
X-original-commit: 83ec944d6f8d534438fd223f44fd82b195aa3c06
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
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>
Stanislav Kurinec