Issue:
When updating section line or note in a confirmed SO, the system tried to compare uom of them causing an error
Steps to reproduce:
1- Install sale and repair apps
2- Create a sale order with adding a product and a section line
3- Confirm sale order
4- Modify section line
5- Save
Solution:
We need to check if the order line is a product before performing the uom comparison
opw-3644939
closesodoo/odoo#148900
X-original-commit: e3cd490ab0e62865b5ad7516643a22c6ba3a3371
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Omar Abosamaha (abom) <abom@odoo.com>
Before this commit:
The taxes column on invoice preview
were displayed abit congested due
to inherited attributes
After this commit:
We have removed inherited attributes
which resolves the above mentioned
issue
closesodoo/odoo#148988
X-original-commit: d7d0cac8da30a15ab0d1d8695024fcb3f8b6ac3b
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Harsh Modi (hamo) <hamo@odoo.com>
Before this commit:
The warning message displayed for E-Invoices with API and
tax ID mismatch was incorrect. It stated: '[0] Unable to send e-Invoice. Create
an API user in NIC portal, and set it using the top menu:
Configuration > Settings.'
After this commit:
The warning message for E-Invoices with API and tax ID mismatch has been
updated. The new warning message now reads: 'Ensure GST Number set on company
setting and API are Verified.'
closesodoo/odoo#148919
X-original-commit: bf4409253597c0feedd0cccb42140a3a878276e1
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Zeel Patel (zepa) <zepa@odoo.com>
Currently, when we try to print a ZATCA invoice after installing the l10n_sa_edi module, the system will always default to printing the Phase 2 QR code on the invoice reports, irrespective of whether or not the invoice itself is for Phase 1 or 2. To fix this, we check if the Invoice has edi_documents, in which case it is marked as Phase 2 and runs as usual. Otherwise, we mark it as Phase 1 and call the initial function.
closesodoo/odoo#148928
X-original-commit: 3d33d18bbe5c462e0b986cb4891a67a14c63eb62
Signed-off-by: Mehdi Bendali Hacine (mebe) <mebe@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce:
- Add an image on the website.
- Save.
- With the HTML editor, change the src of the image (to
"https://odoo.com/logo.png" for example) and remove the
`mimetypeBeforeConversion` data attribute of the image. Note that it is
important to change the src of the image to ensure that the system does
not add the `mimetypeBeforeConversion` data attribute back on the image.
- Enter in edit mode and click on the image.
-> Traceback of type "Cannot read properties of undefined (reading
'split')".
This traceback appears because the `_renderCustomXML()` method of
`ImageHandlerOption` relies on the presence of formats on the list
returned by the `_computeAvailableFormats()` method. Since [1], if there
is no `mimetypeBeforeConversion` data attribute on the image, one of the
format in the list is `undefined`. As `_renderCustomXML()` tries to
perform a `split()` on this format, a traceback appears.
Although the steps to reproduce the result seem tricky, it has been
decided to create a fix for this situation. Indeed, in version prior to
16.4, the equivalent steps to reproduce (in which the `mimetype` data
attribute is removed instead of the `mimetypeBeforeConversion`) do not
lead to a traceback. In those versions, if there is no mimetype on the
image, the options such as "Filter", "Width" and "Quality" are not shown
in the editor panel. The goal of this commit is to apply the same logic
for the version 16.4; hide the "Format" option if the image does not
have the `mimetypeBeforeConversion` data attribute. To do so, the
`_computeWidgetVisibility()` method has been adapted consequently. To
avoid the traceback, the `_computeAvailableFormats()` method has been
adapted. It now returns an empty list if the image does not have the
`mimetypeBeforeConversion` data attribute. As there is no `undefined`
format in the returned list of valid formats, the traceback is avoided.
[1]: https://github.com/odoo/odoo/commit/730588b802506844e6ca54df312333bfd8df1d52
task-3631487
closesodoo/odoo#148882
X-original-commit: 485a5d74198668fa2f2240b4e31a871f36225857
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When browsing a payment provider's payment methods, the "New" button was
disabled because the action did not allow Kanban views.
closesodoo/odoo#148865
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
When the payment provider was disabled, the "Enabled Payment Buttons"
was shown, although it was not possible to enable them yet. The button
is now hidden until the provider's state is set to either 'enabled' or
'test'.
Part-of: odoo/odoo#148865
Current behavior:
When adding a product with a variant, the variant page is not displayed
correctly, it's missing the add to cart button.
Steps to reproduce:
- Create a product with a multi checkbox variant
- Open self order menu on iOS
- Click on the product
- The "Add to cart" button is missing from the page
opw-3614337
closesodoo/odoo#148861
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When the content of the editor is reset, the collaborative selection
should be reset as well. Otherwise, the selection is not reset and
the user can still see the selection of the previous content.
task-3675074
closesodoo/odoo#148826
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Before this commit, when restoring a document was made, it would reset
the content of the editor without any consideration for the mechanism
that detect stale documents and without any consideration for the
collaboration.
This commit fixes 2 problems in one shot:
1) Any change made in the editor after a restore was impossible to
save. The reason is that the restored version would reset the wysiwyg
without the id `data-last-history-steps` of the version in database in
the historyIds of the odooEditor wich subsequently would trigger the
stale document detection, preventing the save.
2) The reset would be propagated to other peers in collaboration. The
reason is the same as the 1st problem, the wysiwyg would be reseted,
not informing other peers of that reset.
task-3675074
Part-of: odoo/odoo#148826
Tune currency cache usage to enhance entry sharing by converting
date_order from datetimes to dates. This change aligns with currency
rates being queried based on dates, enabling the cache to consolidate
entries for identical currency rates on the same date. This optimization
reduces the number of entries and queries, especially for orders made on
the same date but different times.
closesodoo/odoo#148825
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Since b6242264ea9f9f9f42cca4427e30071219ae6a70 a new caching strategy
for reducing the database queries when computing frequently the currency
conversions or rate was implemented. Therefor it isn't needed to use a
local `lru_cache` anymore. The new cache is implemented via
a `depends_context` which each have their own ORM cache lasting for the
current transaction.
Part-of: odoo/odoo#148825
Steps to reproduce
- install the following modules:
- Accounting
- Studio
- Saudi Arabia - Accounting (l10n_sa)
- Go to Settings > Users & Companies > Companies and create a New Company (named `SA Company` for example) with Saudi Arabia as the country in the address
- Switch to the new `SA Company`
- Go to Settings > Accounting
- Choose Saudi Arabia package as the Fiscal Localization package
- Go to Accounting and click on the studio icon (the one left of the user profile avatar)
- Click on reports
- Clear the filters
- Click on Invoices
- Click on the Company tagline box
- In the select box shown, choose `elif: o._get_name_invoice_report() == '|10n_gccarabic_english_invoice'`
- U can notice how the template is not rendered correctly
Invistigation:
- the major issue was the flex-direction: column; in https://github.com/odoo/enterprise/blob/e892bc8f022ed3962de06a61c1be181c89cdc831/web_studio/static/src/client_action/report_editor/report_iframe.scss#L170C1-L187C2 that caused the table header to be viewed as blocks
- Some xml tags / classes needed to be refined to enhance the layout
opw-3544938
closesodoo/odoo#148821
X-original-commit: db9498ccf8a6d5c51e691cbab04fc134ae310da9
Related: odoo/enterprise#54029
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
Currently in 17.0, when adding an additional component (not present on
the BOM) on a Manufacturing Order, the Consumption Warning wizard shows:
- to consume: amount of additional component
- consumed: 0.0
Additionally, this reversal makes the 'Set Quantities & Validate' button have
the same result as the 'Confirm' button for the additional component lines.
task 3670356
closesodoo/odoo#148809
Signed-off-by: Stéphane Diez (snd) <snd@odoo.com>
Steps to reproduce:
- Create a PO with a tax
- Confirm PO and bill it
- Deactivate tax
Issue:
Tax is shown on bill but not on PO
Solution:
Make sure that we display tax even if inactive.
opw-3631087
closesodoo/odoo#148778
X-original-commit: 4e424750eccff168c3cbb1a3f8411b35905717f3
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Mattis Megevand (mmeg) <mmeg@odoo.com>
In v16 the configuration of a pos_config got moved from Point of Sale
to Settings, with new settings fields related to pos_config fields.
The create method got overriden in point_of_sale
to write values on the current pos_config
after the creation of the new settings.
The side-effect of doing so is that each creation of a res_config_setting,
i.e. after changing any given setting (pos-related or not), triggers a
write on ~50 fields of the current pos_config. Among those fields there are
modifying_relations fields that trigger recomputes on pos.order. Because
pos.order can grow quite big in some databases (> 200.000 pos.orders), it
makes it almost impossible to change any setting in these database. They
reach a TimeoutError on SaaS/SH.
To fix this, this commit filter pos_fields_vals to only write new
values on pos_config. If no value got changed since the last settings
creation, no write is triggered, and no recompute happens.
Because we are in the context of res.config.settings create, and all
the pos_config settings fields are related fields, everything should be
in cache and no (or very few) query should be executed when doing this
filtering.
opw-3547106
opw-3508239
closesodoo/odoo#148756
X-original-commit: 72f7c0d7d16a1b791bba61fd885261227f73d263
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Aurélien van Delft (avd) <avd@odoo.com>
Add a missed condition to only show the label if the value is set
closesodoo/odoo#148650
X-original-commit: 4766809fdd4c04eb2258da4ff9e312dac7c09ea0
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
In this commit we have fixed the line break issue when we submit a feedback
for task and ticket.
steps:
- Install helpdesk
- Go to helpdesk > team
- Activated customer rating
- Set the rating template in the ticket stage
- Create a ticket with the customer and move to the next stage
- Open the mail and submit a rating and message
- Open ticket and check customer message
task-3268763
closesodoo/odoo#148644
X-original-commit: 185adf6fb487fa260bb6dfe985638bc545de7fa2
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
As a reminder, the readonly expression in grouped kanban can enable or
disable the drag and drop feature. If the view is not reaonly but the
field in the arch on which the view is grouped is readonly, the drag
would be disabled.
Before this commit, there was a regression introduced in commit
ba1a5509fa that made the kanban record not
able to evaluate the readonly expression in the fields.
This commit fixes the issue by making the kanban record evaluate the
provided expression. It does not however correctly evaluate the
expression if it contains another field as the drag and drop feature
can be enabled at a view level, not at a per record level. It would then
resolve to not readonly.
Task id 3611116
closesodoo/odoo#148533
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
As Czech legislation is changing its VAT structure on 1.1.2024, a new 12% tax
is added. Also some account were wrongly named, misclassified or missing. The 15%
taxe is kept in lower version for backward compatibility.
task-3609608
closesodoo/odoo#148409
X-original-commit: c0aba48f3c4fd2ebfa140fbe237ccde635e17b34
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Simon Morais Da Cunha (smdc) <smdc@odoo.com>
Steps to reproduce:
- Install `CRM` module (for test purposes)
- Create a lead and set the name, email, phone, company name and
contact name
- Save the lead
- Click on `Send message` button in the chatter
- Uncheck/Check the recipient checkbox
- Save the partner
- Discard the changes on the lead and open the partner created
Issue:
- In the wizard, the `phone` value is not set with default value and
the name is set with the company name instead of the contact name
- On the partner created, the company and phone are not set
Cause:
The default values (used in the partner creation wizard) retrieved
from "/mail/thread/data" route are not set on the recipient object.
opw-3512045
closesodoo/odoo#148213
X-original-commit: 372fe2fe61e3121b27bf1305dfac8fbf0ff8e9b5
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
This traceback arises when the user tries to reinstall the 'pos_restaurant'
module
ParseError:
Parse error rises
When users try to reinstall the 'pos_restaurant', a traceback will be
generated. Because duplicate 'MRCSH'records exist, they raise the ParseError.
Which leads to the traceback from here
https://github.com/odoo/odoo/blob/8b4f4f2e373896fcaa50f6ee55467274f8e440d5/addons/pos_restaurant/models/pos_config.py#L134-L139
After applying this commit, it will resolve the issue by if the
pos payment methodexists, returning the values otherwise create it.
sentry-4736057055
closesodoo/odoo#147539
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps:
- install to project_enterpise module
- Go to project > all tasks in the Gantt view
- Group by customers
- Filter any customer
Issue:
The wrong domain is passed in the search method so traceback occurred.
Cause:
Currently, we don't replace `child_of ` operator with `ilike` in _search_on_comodel method so
child_of is passed in the search method and orm is not handled.
Before this commit domain:
`[('name', 'child_of', 'admin')]`
After this commit domain:
`[('name', 'ilike', 'admin')]`
Fixed:
We correct the domain.
Issue in this commit-
https://github.com/odoo/enterprise/pull/41257/commits/57eb5b72796e0aeff6d8368219281760acb7c307
task-3625825
closesodoo/odoo#144989
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When `test_display_name_for_empty_payment_details` was tested around
midnight, the test would fail because it compares the current date with
the token's create date, which would be the day before.
closesodoo/odoo#148781
X-original-commit: 87f94715a09b7681bcd92d1cba4f84d30918c502
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Current behavior:
Before this fix, when you sent the order to the kitchen, the preparation
changes were not saved directly. So if you refreshed the page right
after sending the order to the kitchen, the preparation changes were
lost.
Steps to reproduce:
- Open a POS restaurant session
- Add a product to the order
- Click on Order
- Refresh the page (F5)
- Go back to the table were you made the order
- The product still appears as not sent to the kitchen
opw-3614345
closesodoo/odoo#148755
X-original-commit: 8f33d6fa0261373fee276efd20dcbf75e95e1e28
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
The parser of the library we use to extract strings to be translated
(python-babel) doesn't handle escaped newlines in the same way as the
JavaScript parser. The resulting mismatch makes the content that uses
them untranslatable.
for example:
```js
const hey = _t("slt \
çv ?"
);
```
is exported as "slt \nçv ?", while the content of the variable is
"slt çv?"
This commit removes faulty occurrences from the code base and re-exports
the corresponding POT files.
*: point_of_sale, pos_sale, project, web
closesodoo/odoo#145971
Related: odoo/enterprise#52617
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Steps
=====
- Install sale_timesheet
- Create a project shared (in edition) with a portal user
- Creata a task with a subtask and log timesheets for the subtask
- As a portal user open the parent task form
- Go in the timesheet tab
- Click on the button "Sub-tasks Hours/Days Spent" at the bottom of the
page
Issue
=====
An access error appears for a res.partner record.
Cause
=====
https://github.com/odoo/odoo/pull/135528 introduced the field
allowed_so_line_ids on model account.analytic.line. This field is
computed based on the values of the field
commercial_partner_id (res.partner relation). However, portal users have
no access to res.partner records and the presence of this field in
account.analytic.line view (for timesheet) therefore raises an access
error for portal user.
Fix
===
A sudo is used in method _default_sale_line_domain to be able to fetch
the ids of the partners linked to the timesheet, even as a portal user.
task-3572112
closesodoo/odoo#139866
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
A class s_turnstile added to the script tag was missing. Without it,
the function cleanTurnstile called by the destroyed cannot clean the
script tag.
So it would result in the script being present several times in the DOM
after some manipulation.
fixes https://github.com/odoo/odoo/pull/147886closesodoo/odoo#148783
X-original-commit: e5af8a16fccc784e21fcc30d891fafb5d0951d17
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Steps:
- install project ,website,saleorder
- open project ,share a saleorder project to admin from the share button
- then go to website,click on projects
- pen the shared project
- In that the size of the chatter is small
Issue:
- The size of the chatter is abnormally small
Cause:
- The problem occurs because the width of the chatter is less
Solution:
- By increasing the chatter size the problem can be solved
task-3549279
closesodoo/odoo#148770
X-original-commit: a2efc1a0a1b831f4dd356661d1ef40e9174af73b
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Fix various use case of HTML encoding / escaping in mail flows. Depending on
functional flow HTML entities could appear as they were not correctly
managed as valid HTML.
Notably when managing attachments in '_process_attachments_for_post' we
should return Markup-ized HTML to be sure it is considered as valid in
other post processing.
Task-3675159 (Mail: correctly escape HTML when updating content)
Task-3619348 (Mail: propagate markup flag when processing attachments)
closesodoo/odoo#148769
X-original-commit: f4bf63077d4129807e00e15b833e47623869491f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a customer with a sale portal link confirms the order, the
registrations in the order won't have the data for the partner of the
order which would be the expected default.
In 6cfdf64a86 the intention is to avoid
that registrations made on the website by anonymous users are registered
with the public user. There's a side effect to this in the portal
workflow though.
We can reproduce it like this:
- We need a payment aqcquire wich confirms our sale order (we can use
payment demo)
- In backend, create a sale order with the desired partner and a
registration to an event.
- Send the quotation to the partner.
- With the link portal (and without being logged in) sign and pay the
order with the demo payment aquirer.
Result:
- The order gets confirmed.
- The registrations are created with no partner (booked by).
So this fix avoids the original issue (having a public user as the
registration partner) but saving the case where we are confident about
the booked by value.
TT44782
closesodoo/odoo#148758
X-original-commit: 28020f2046b0183293a06ab03d4724173e3a0fa0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue:
The query for the Tax Report Account>Tax is slow.
Analyze:
The query for the Tax Report is huge, and exceeds the
join_collapse_limit threshold
(https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-JOIN-COLLAPSE-LIMIT)
of postgresql (8 by default and on our servers). It is then needed to
help the query planner to optimize this
query. Running the query with increased join_collapse_limit and checking
the explain analyze, helps in this process.
Fix:
The query planer with increased join_collapse_limit made the
res_currency joins at the very end of a truncated query.
Moving the res_currency join help as the inner join is made on AM^2 on
current position. Moving it after the base_line reduce it back to AM^1.
Benchmark:
| # Input data | Before PR | After PR |
|:-------------:|:----------:|:---------:|
| 271000 AM | 900 s | 13.24 s|
| 25000 AM | 180 s | 1.5 s |
| 51 AM (demo data) |52ms | 80ms |
Related task:
opw-3581671
closesodoo/odoo#148740
X-original-commit: b92b6846bfa7de8a41a6808e347fb78980baa4eb
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Benjamin Hanquin (beha) <beha@odoo.com>
Co-authored-by: Julien Launois (jula) <jula@odoo.com>
*: website
This basically reverts the parts of [1] that are the known cause of race
conditions in runbot tests (in particular, the link tools one:
`test_15_website_link_tools`). But more importantly, this just did not
make sense to stop observing changes for async period of time, at least
unless there is no alternative given the state of the related code.
Commit [1] test-hack was actually adapted with [2] which probably made
it even more unreliable and hacky.
On top of that, this commit is of course trying to restore whatever
purpose this was made for ("dirty" flag addition, the history steps
recording, etc). Although fixing those the most robust way would
probably require a deeper refactoring in master and other stable fixes.
Note: in this forward-ported version, the test is still disabled on
runbot and broken for other reasons. Those will be fixed later.
[1]: https://github.com/odoo/odoo/commit/8cab404dce3a65c0bdd635a93682ee14282a3ebb
[2]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35
runbot-18747
closesodoo/odoo#148728
X-original-commit: 003422a73f0b5fb5540fbf2bd95a26a6dd663530
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor
The editor has a feature that allows to automatically select a whole
paragraph on click when that paragraph contains text by default. At the
origin, this happened at every click on the element, until its content
was replaced, by typing something while it is selected or the cursor is
inside. Placing the cursor inside was actually impossible by clicking on
the element, since this forced a selection on the whole text again.
Since [1], that behavior changed (for no apparent reason): only the
first click forces a selection on the element. This is done by removing
the marker class from the element ("o_default_snippet_text"). Also, the
code which removed that class while typing was left behind... even
though it did not work anymore due to a code typo.
This commit fixes that without changing the main behavior:
- On click, we do not remove the marker class anymore, but only force a
selection on the text if it was not already seen before. Small change
of behavior: not changing the text and coming back later in edit mode
will force a selection on the text again on click.
- While typing, the code removes the marker class and thus the text will
never have a forced selection again (fixed the code typo).
Note: we may reconsider restoring the behavior there was before [1], in
master. Automatically selecting default text that was never changed
could indeed be better, although it will require better code to allow
placing the cursor inside easily anyway.
The main purpose of this fix is to avoid a mutation of the DOM on click
(removing the marker class). Indeed, this wrongfully marked the page as
dirty.
Steps to reproduce:
- Enter edit mode
- Add a "Text - Image" snippet
- Save
- Enter edit mode again
- Click on the first paragraph of the snippet (=> it is auto-selected)
- Click on discard
=> A popup appears to say you will lose your changes... while you did
not make any.
[1]: https://github.com/odoo/odoo/commit/912996fe902c41cafa12dcfe09713ce9857f95ab
Related to runbot-18747
X-original-commit: 3cc5bbcab641d7d436ebfbb0f160c9e0d77da142
Part-of: odoo/odoo#148728
*: web_editor
Commit [1] made the multiple drag and drop feature of the editor stop
using jQuery and used our own implementation. Unfortunately, the
initialization of that implementation in the case of the "drag column
on image move" feature marked the page as dirty by mistake.
Steps to reproduce:
- Enter edit mode
- Add a "Text - Image" snippet
- Save
- Enter edit mode again
- Click on the image of the snippet (and do not do anything else)
- Click on discard
=> A popup appears to say you will lose your changes... while you did
not make any.
[1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76
Related to runbot-18747
Part-of: odoo/odoo#148728
*: web_editor
Next commits will extend the main new test to make sure the flows they
are fixing are not wrongfully marking the pages as dirty. This commit
introduces it on its own as it deserved some more detailed explanations.
In 15.0, where this commit is being merged, the final version of the
test was failing for no apparent reason on staging only. This is because
the staging builds are made with more apps... which fill the website
menu with more items in such a way the "+" auto-fold menu feature comes
in play. That feature is marking the page as dirty by mistake in this
version, 3 different ways for 3 different configurations:
- the menu is not folded outside of edit mode and when entering edit
mode, the "+" appears and some menu are folded
- the menu is folded outside of edit mode and when entering edit mode
the resize actually makes it so a different set of menu is folded
- the menu is folded outside of edit mode and when entering edit mode
it stays the same (known to have been broken because edit mode
tweaks the dropdown behavior)
The first problem with this is actually the way we check the page is
dirty in case of discard: we check the whole DOM and compare it to the
way it was when entering edit mode... the whole DOM, including the non
editable parts. This is wrong by definition but it is also weird that it
does not match what is done when we *save*: where we only consider
sections that are explicitly marked as dirty (.o_dirty) and other
exceptions. This can't be changed in stable though, some save / discard
override may rely on this (not marking with the o_dirty class etc).
In 15.0, the original commit of this forward-ported version fixed the
3rd case described above, which was less risky than fixing the 2 others.
The cause for the DOM diff in that case was the `data-toggle="dropdown"`
which mysteriously reappeared between the moment we check the "initial
DOM" and the "DOM when we try to discard". This was because of [1],
which makes the dropdowns behave differently in edit mode, combined with
the fact that the "+" menu is re-rendered after each resize (and one is
triggered when entering edit mode since [2], originally for that
actually). That behavior is however apparently not needed for the "+"
dropdown, so we simply disable it. Some lower level fix is still needed
but will be done in master, as the real problem falls in the dirty page
detection system. A test was added for this specific third case.
In 16.0, this is different: all 3 cases seem fixed, probably indirectly
thanks to the website-in-iframe refactoring at [3] and the bootstrap 5
migration at [4]. Not sure. This forward-port commit thus only adds
tests and a bunch of comments. Note that what was said about the 15.0
version was actually not entirely true: "That behavior is however
apparently not needed for the "+" dropdown, so we simply disable it." is
actually wrong. Indeed, it changed the behavior when clicking *outside*
of the extra items menu (which is less important). A patch in 15.0 will
be backported anyway to explain that.
To make the final test pass, it ensures most menus are removed so that
the "+" feature is basically disabled always during the test. Behaviors
will of course be fixed in further versions.
Note that in this 16.0 forward-ported version, a test kinda already
existed for this... although it was badly written and the code that was
merged with it actually worsened the dirty check behavior. See [5].
This commit adds comments around some more problematic parts.
[1]: https://github.com/odoo/odoo/commit/fe67b34f1a03d838df82a1307cf6467f994a8f3b
[2]: https://github.com/odoo/odoo/commit/392c91cda3133b921e9aca9a7b1c511231027438
[3]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[4]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[5]: https://github.com/odoo/odoo/commit/650a97d1bd59254cc2115d54d58940b6112a8d70
Related to runbot-18747
X-original-commit: a0b741a53fef6a2a15d9283397dd7ec22d624382
Part-of: odoo/odoo#148728
This probably does not change much but it short-circuit a bunch of code
when we click outside of an editable zone and something in the DOM
happens. Allows for easier debugging of mutations. It also avoids the
creation of a jQuery object when the mutation is about changing a
contenteditable attribute, I guess any small perf improvement should be
welcomed.
Related to runbot-18747
X-original-commit: f93a2da57e1424898fbf6e157945e2afa97be89e
Part-of: odoo/odoo#148728
The original issue (in saas-16.4) has been fixed in 17.0
by refactorings.
This commit only fw-ports the test
Steps to reproduce:
- Open the Subscription app
- click on the list cog wheel
- Spreadsheet > Insert list in spreadsheet
- Select the blank spreadsheet and insert the list
- right click any cell with a list function
- click on "See list properties"
=> boom `undefined is not iterable (cannot read property Symbol(Symbol.iterator))`
The list domain has the shape `["subscription_state", "not in", ["2_renewal", "5_renewed", false]]`
`false` makes the domain selector crash.
opw 3670344
closesodoo/odoo#148727
X-original-commit: cfdc9c6d62050e3aac4bf18f374e4772ce18a504
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
The jsconfig.json file is used by editors to provide autocompletion
but the paths were not updated when it's used in the enterprise
path.
closesodoo/odoo#148725
X-original-commit: c41824c35f26708bece94a6bb507496a259172c0
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Before this commit, a Field using the useInputField hook can ignore values
from an onchange in some cases.
Problem:
=======
In order to know if it should apply the value of an onchange on the field's input,
the useInputField hook uses a useEffect which will check if the field is
not dirty (being edited) and if it is not invalid. If it true, it will apply
the value returned by getValue which often corresponds to record.data[fieldName].
By executing getValue, it will therefore start to observe changes in record.data[fieldName]
until the next render. If getValue is not executed then changes applied
by onchange on record.data[fieldName] are ignored because we don't observe record.data[fieldName].
Solution:
=======
Always execute getValue in the useEffect to always observe changes on
record.data[fieldName] and apply them correctly on the input if needed.
(It s a hack but we don't have a better solution for now)
How to reproduce:
================
- Go to a Form view with a field B with onchange and a field A (char field)
- Edit field B (an onchange is in progress)
- Insert a value in the input of field A
- The onchange is resolved with a value for field A
- The value in the input for field A does not change (because the field is in edition)
- Click outside the input for field A (trigger change event)
- Edit field B (an onchange is executed directly)
Before this commit:
The value returned by the second onchange is not visually applied to
field A. The old value is still present in the input.
After this commit:
The value returned by the second onchange is correctly applied to field A.
Its input contains the value of the onchange.
closesodoo/odoo#148711
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The problem was the hard coded `@Mitchell Admin` in the expected result.
The case can be different when the demo data changes.
Change the test and make it fixed in all cases.
closesodoo/odoo#148710
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Currently, when you attempt to uninstall an industry module, you are met
with a 'record not found' error.
Cause
-----
The list of industry modules is fetched from `odoo.com`. Since they do not
exist in the database, they are all assigned an ID of `-1`.
This ends up causing an issue in case of uninstall because no record
with and ID of `-1` can be found.
Fix
---
When a module is installed, it gets a record in the database (and ID).
The fix simply uses that ID if it exists, instead of `-1`.
opw-3662239
closesodoo/odoo#148456
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
This commit adds the simulcast feature to calls when relayed by an odoo
SFU server, this allows for better bandwidth management by scaling down
resolution instead of losing packets.
closesodoo/odoo#148276
See: https://github.com/odoo/sfu/releases/tag/v1.1.0
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- Using a company whose currency is USD, make sure to have a rate change with EUR a week before Today.
- Create an analytic plan with Default Applicability set to Mandatory.
- Create an analytic account for the plan.
- Create a Storable Product with a Product Category that has FIFO Costing Method and Automated Inventory Valuation.
- Create a Request for Quotation in EUR using the new product and the new analytic account.
- Confirm it, click on Receive Products, then Validate.
- Go back to the RFQ and click on Create Bill.
- Change the date to two weeks ago (in order to trigger an exchange difference).
- Confirm it.
Current Behavior:
A `ValidationError` is raised in `_validate_distribution()`: "One or more lines require a 100% analytic distribution."
Cause:
This happens because the exchange difference journal items are created without `analytic_distribution` even though they should, since it was set as mandatory.
Solution:
Make sure the `analytic_distribution` is properly set when creating stock valuation lines.
A test is also added to cover this use case.
task-3582164
closesodoo/odoo#147387
X-original-commit: fafcf452c68aad27754a8c9bd7bde1742be61cb8
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
To reproduce (16.2 and >):
1. Install pos_restaurant
2. Open the Shop pos session
-> "Kitchen Note" button display
=> Unintended as this button does only make sense in restaurant
Before this commit:
The button actually shows due to `iface_orderline_notes` value being
set to `True` by default.
After this commit:
The setting value is unset (for shops) to prevent the button to render
opw-3651750
closesodoo/odoo#148700
X-original-commit: afd9c9faaff9603eb1a11dc79ea3053a1eac98fb
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
In odoo@98ca5140baf96, a test using a product of type 'product' was
added. Since this type is introduced in stock, stock needs be installed.
Since the delivery module was split in saas-16.2 to remove the
dependency to stock, this test needs to be moved in website_sale_stock.
Build error 48757
closesodoo/odoo#148691
X-original-commit: c517b45eb36b02c2f0679be79da565087c5e48ca
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
In e0297bd, we fixed the inverse field values of the new record during
the onchange. But we actually filter out inactive records by doing
record[self.name] in _update(). And since the XtoMany field cache
values should always contain inactive records, we need to add
with_context(active_test=False) on records.
Also remove the useless 'if value', value is always truly because it
is always a record.
Note that this solves a performance issue in our production, because
in order to filter out inactive records, we need to fetch the active
field next to every prefechable field.
closesodoo/odoo#148675
Signed-off-by: Raphael Collet <rco@odoo.com>
OmarAbosamaha
