On install, `hr_work_entry_contract` only associates work entries to
contacts which are open or closed.
However during its execution (?) `hr_work_entry_contract` generates
entries associated with `Mitchell Admin Contract`, which is a draft
contract. As a result, when uninstalling then reinstalling
`hr_work_entry_contract` it is not able to re-associate the entries to
the contract, and thus can't reinstate the `required=True` on
`HrWorkEntry.contract_id` either, which is a "reinstallation failure"
on the CI.
A simple solution is to create the contract closed, though it would
also be a good idea to not be able to create work entries associated
with a draft contract either, maybe?
X-original-commit: 6b7f3f6ec40eb819dd1d94a94722610a63d5697a
Part-of: odoo/odoo#121522
Since the "dirty flag" refactoring of
384fda2c2a
`IrModelFields._prepare_update` did not cope well with fields missing
from the python-side models, which can during uninstallation for
custom fields (possibly because the script loads the registry
incorrectly, not entirely clear).
Because of a custom field created by worksheet linking to it, the
removal of the `project.task` table would fail, making the
reinstallation of project fail to restore several constraints.
This case was actually handled correctly just a few lines above when
trying to resolve field dependencies, both record and field would be
checked for their presence before actually trying to use them.
Getting the model from the registry / environment has not been noticed
to break uninstallations, but might as well do that too so everything
lines up, and just in case.
X-original-commit: 05aca6ee4ce795b85b90430efd761f0cd3a6d5a3
Part-of: odoo/odoo#121522
Issue discovered in the uninstall (and reinstall) of sale_project: a
dump has ~100 tasks, when reinstalling `sale_line_id` has to be
initialised, this is done by marking `sale_line_id` on all extant
tasks as to-recompute, which triggers their computation on the next
`flush`.
Because it's a recursive field, `Field.recompute` ensures only one
record at a time gets recomputed (as there could be cross-dependencies
in the recorset which protection would prevent from resolving).
As the field computation runs, it accesses itself, which triggers a
cache miss, which triggers a `_fetch_field` (to get the currently
stored value), this calls `_read`, which flushes the field we're
trying to read.
The problem here is that for efficiency the cache miss will look for
all records in the cache without a value for the
field (`_in_cache_without`) and try to `fetch` on them as well. This
means rather than not doing anything in flush, we're going to
`Field.recompute` on all records except the one selected the first
time around, which repeats the cycle until there is no more additional
record found in `_in_cache_without`, which could trigger the next
round of `recompute`, and the entire thing unwinds, and we probably
perform a ton of unnecessary additional `compute_value`.
Except that doesn't even happen, because the process from one compute
to the next takes 12~13 stack frames, which given the default
recursion limit of 1000 gives a hard limit of 76 fields before hitting
a RecursionError. As this is less than 100, a recursion error [is what
we get](https://runbot.odoo.com/runbot/build/31726625).
In 15.2, this was fixed by only expanding the fetch on non-recursive
fields, pessimizing recursive
fields (5c2511115b14299516fce4aa3737a62faaf5b653). Test-wise this only
impacted mail performances and in a relatively minor manner.
In 16.0, the mail tests actually match already (so that part was
skipped by the cherrypicking) however this impacts the knowledge perf
tests much more significantly e.g. `test_article_creation_multi_roots`
gets +9 queries when creating 10 top-level articles, which is a bit
much.
So use an alternative which is ugly as hell but which I didn't
consider for 15.2 (may want to backport it one day if the current fix
is an issue): catch the recursion error and use the existing
fallback (of fetching just the requested record's field without
expanding the recordset).
This likely makes for a pretty inefficient situation in the original
case as we're certainly going to hit the recursion limit repeatedly,
but that still fixes the issue, and it avoids deoptimising cases which
fall short of the recursion limit (resolving under 60 records or
so).
Plus despite creating giant stacks we might actually get good
efficiency as we're going to hit recursion limits repeatedly but
that's pure python, once we fall below the limit we can resolve
everything at once with a single SQL query (or something along those
lines).
X-original-commit: 9e71094582ec4c9b719431e77538da8f91ffa9e3
Part-of: odoo/odoo#121522
Uninstallation does not cope well with `setup_models` being performed
unconditionally as those will dramatically alter registry states, and
resurrect computes which the uninstallation has disabled: rather than
try to update registry models in-place (which is rather fraught) the
uninstallation deletes the columns, tables, and `ir.*` reflection
records and only after all of that is done does it reset the registry.
This means while it does fix up the registry caches (`field_depends`
and `field_triggers`) as it goes, resetting those may cause the
recomputation of fields whose columns have been deleted, possibly
based on dependencies whose columns have also been deleted.
As such these kinds of manipulations should either be performed in
`@ondelete` methods which don't get executed during uninstallation, or
they should be gated behind an uninstallation check.
In crm the latter is necessary, as `ondelete` runs before `unlink`
actually executes, and the registry reset would run too early (and
unnecessarily).
In base, only the latter is possible as we're not in `unlink` itself,
instead `IrModelFields._prepare_update` is called *during*
uninstallation and its trailing `setup_models` causes the issue.
X-original-commit: 357b9f2c9fd44e14e5b7c9d3c17f1794691986f3
Part-of: odoo/odoo#121522
When modules get uninstalled, first the uninstall process will drop
all the fields (removing all the columns) then it drops all the
models (removing the tables).
When uninstalling mail, this means the various (res_)model(_id) fields
don't exist anymore by the time we're deleting models, so the queries
blow up.
Skip this step if we're unlinking the mail models, it means the tables
have already been dropped, so there's nothing to delete anymore. This
should not use `ondelete` because we *do* want to delete records from
those tables when deleting modules which depend on mail, and thus have
mail stuff associated with their own models which we're deleting.
X-original-commit: e43155f940c1f0ba30378d110fc371012d791e32
Part-of: odoo/odoo#121522
Confusion between uninstall hooks can apparently trigger errors during
uninstallation as two hooks can confuse one another?
In this here case, the issue triggered during the uninstall hook of
`account_accountant`, which apparently combines with the uninstall
hook of `industry_fsm_sale` to trigger an invalid in-memory state for
`project_project`. An implicit flush during the hook then blows up
with a check constraint error.
Flushing at the end of the `industry_fsm_sale` hook or at the start of
the `account_accountant` hook fixes the issue, so might as well flush
after each hook to ensure whatever they did using models is pushed to
the database and in good shape (hopefully).
X-original-commit: b28e9a7066d29d395421a11df2b9e170fb20d35a
Part-of: odoo/odoo#121522
There is no action that uses the search models/components available in
the legacy control panel. We remove those.
closesodoo/odoo#121433
Related: odoo/enterprise#41078
Signed-off-by: Géry Debongnie <ged@odoo.com>
RATIONALE
Purpose of this change to rewrite the formatting done on messages displayed
on simple frontend i.e. portal chatter widget and project chatter.
We stop calling 'message_format' which computes a lot of unnecessary data
and sends too much information to frontend. We choose to instead manually
handcraft the returned data, already tailored for frontend widget.
SPECIFICATIONS
Remove call to '_message_format' in 'portal_message_format'. Instead have
a list of properties (fields or computation based on fields e.g. rating publisher
information) that can be overridden in sub-addons. Use those to generate
the data used by frontend chatter widget.
Remove extra formatting or data computation done in JS files. Do it directly
in 'portal_message_format' in order to have clean information sent.
This change targets mainly portal and portal_rating. Making those modules
Independent from backend message formatting allows to save queries and
also to avoid sending useless information to the frontend.
SIDE SPECS
Improve 'message_format' tests, and make new specific test for its portal
counterpart.
Provide some fixes for bugfixes that occured during the testing of this
task. Those are not crucial for stable, so currently kept in this master PR.
Task-3322905
closesodoo/odoo#121104
Related: odoo/enterprise#41056
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to add performance tests for 'portal_message_format'
that is used when displaying chatter in frontend (e.g. customer portal). It
allows to keep an eye and to optimize part of that code allowing cross-apps
optimization.
Task-3322905
Part-of: odoo/odoo#121104
Current rule to edit publisher fields (comment, ...) is to have the editor
group. However when having only portal, this group does not exist. The
feature should work as a standalone feature without depending on website.
The rule is then updated as follow: either the current user belongs to the
editor group (if it exists), either it can write on the related record
(given res_model / res_id).
Currently no crash in standard addons occur because its main usage is in
eLearning application, where editor can answer and update publisher comment
from the frontend (course review).
Task-3322905
Part-of: odoo/odoo#121104
Currently when modifying publisher comment, publisher partner id and date are
synchronized if not given in order to always have coherent values. In this
commit we do the same at create. Even if won't happen frequently better ensure
values coherency. Moreover it helps writing tests.
Task-3322905
Part-of: odoo/odoo#121104
'legacy' parameter was present only for a specific part of attachments
formatting. It was used only for portal, as the widget used in frontend
was not using the 'discuss' orm-like convention.
As portal formatting is now independent from mail/discuss formatting this
can be safely removed, simplifying the API.
Task-3322905
Part-of: odoo/odoo#121104
RATIONALE
Purpose of this change to rewrite the formatting done on messages displayed
on simple frontend i.e. portal chatter widget and project chatter.
We stop calling 'message_format' which computes a lot of unnecessary data
and sends too much information to frontend. We choose to instead manually
handcraft the returned data, already tailored for frontend widget.
SPECIFICATIONS
Remove call to '_message_format' in 'portal_message_format'. Instead have
a list of properties (fields or computation based on fields e.g. rating publisher
information) that can be overridden in sub-addons. Use those to generate
the data used by frontend chatter widget.
Remove extra formatting or data computation done in JS files. Do it directly
in 'portal_message_format' in order to have clean information sent.
This change targets mainly portal and portal_rating. Making those modules
Independent from backend message formatting allows to save queries and
also to avoid sending useless information to the frontend.
Task-3322905
Part-of: odoo/odoo#121104
Purpose is to improve the depth of 'message_format' performance tests by being
multirecords-enabled, in addition to being multimessages enabled. We also add
more 2many fields in order to better see their effect (notably link previews
and reactions, recently added).
Task-3322905
Part-of: odoo/odoo#121104
Update counters to match current runbot state. Several changes (ORM, mail
code organization) lead to some counters being obsolete.
Task-3322905
Part-of: odoo/odoo#121104
For performance reason, we avoided computing goals for the set of users
that didn't log in recently (See ec0c0f29).
However, users can stay logged in for a while without having a new "log
in event" (password asked), such that active internal users can keep
old values in their challenges when reports are sent, which is not good.
Until an improvement can be implemented in master, we drop this time
constraint for active internal users.
A test is added, checking the behavior of the method called by the cron.
Task-3226408
closesodoo/odoo#121506
X-original-commit: 6c77dd822c719a2181bac1d69130e5c4e8ef70fa
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
1- Create a BOM for a product, define an Operation on the product
2- Link a Google Slides document to the Operation as the Operation Worksheet.
3- Define an instruction on the Operation
4- Set Step Document to Specific Page of Operation Worksheet and define a page.
Issue: The step will not load the document.
Cause: tablet.js passes the wrong value to let know the viewer is a google slide url. Also when the good
value is passed the viewer always show the first page. That's because the SlideViewer has the page set in the
setup() method so it never change despite we change the step in the same document.
opw-3165142
closesodoo/odoo#121477
X-original-commit: 2160115647932ef86db3afc59b7f193075c94fd0
Related: odoo/enterprise#41098
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Djoumatchoua Eteil Junior (etdj) <etdj@odoo.com>
Steps to reproduce:
- Log in as admin
- Install `eLearning` module
- Create a course and add a youtube video as a lesson
- Publish the course
- Go to the website and click on the course
- Enable `Editor` mode (top left corner)
- Click on lesson to open it in fullscreen
- Click `Back to course` button
Issue:
Video is playing in the background.
Same issue occure with video snippet in the website editor (by default
video is mute but still playing in the background).
Cause:
When editor mode is enabled, there is a fallback iframe that clone the
content of the current page that we leave into it.
Since the youtube video has `autoplay=1` in the URL, it will
automatically start in the fallback iframe.
Solution:
For regular website pages, remove the `autoplay` param from all
media video iframes urls (targeting all `div.iframe` that have a class
`media_iframe_video`).
For eLearning, override the `WebsitePreview._cleanIframeFallback`
method to remove the `autoplay` param from youtube videos URLs.
opw-3226002
closesodoo/odoo#121475
X-original-commit: ad78585cd514f5ff16647572d34937c18a112529
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit task action from kanban click and from
stat button does not have same behavior like kanban click
does show archive task for archive project and does not
display New button while other on does not.
This commit make both action consistance to have same
behavior in both actions.
task-3224627
closesodoo/odoo#121473
X-original-commit: c95278e78325aa3831f6bfb02a7f3e377d0a8028
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit fixes a bug with the navbar links in the header of a website
on mobile. When the text of a link is long enough to be wider than the
screen, the text does not wrap to the next line as intended, but instead
overflows to the right outside of the screen, causing part of the text
to be hidden.
Steps to reproduce the bug:
- Edit the text of one of the menu links on a website to make it longer
than the width of the mobile screen.
- Bug: In mobile view, part of the link text is hidden.
This bug occurs with both the "default" hamburger type and the
"off-canvas" hamburger type.
opw-3233684
closesodoo/odoo#121464
X-original-commit: eae10f2e154a1b6bf9f385460b1371faf9869a3f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Before this commit, there were cases where toggling the grid mode did
not work correctly. These cases are:
- when a snippet has None columns (e.g. Cover) and that an inner snippet
containing a row (e.g. Form) was dropped into it,
- when a snippet has some content outside its row (e.g. Picture) and
that an inner snippet containing a row was dropped in this outer
content,
- when a snippet has some content outside its row (e.g. Picture) and
that an inner content (e.g. Alert) was dropped in this outer content.
The first two cases happen because the row that was taken into account
when toggling the grid mode was the first `.row` element found in
general, instead of only considering the container children. Therefore,
what happened in these problematic cases is that the row found was the
inner snippet one, which should not be the case and caused the toggle to
fail because it was trying to put the element inside itself.
The third case happens because the `div` elements were excluded when
placing the outer content in a column, instead of only excluding the row
element.
This commit fixes these issues by only considering the container
children when looking for the row element when toggling the grid mode,
and by filtering out only the row element instead of every `div` when
creating a column for the outer content.
task-3279191
closesodoo/odoo#121393
X-original-commit: f94fe1d40f05a8dbb42f0f2a95d3fff68a3af0ec
Signed-off-by: Dieleman Guillaume <gdi@odoo.com>
Before this commit, input size of thread name was bigger than
the description one. This happens because the input is sized
according to the font size, and the thread name was bigger due
to `lead` classname.
This commit fixes the issue by reducing the padding of input of
thread name input, so that both input have the exact same height.
Part-of: odoo/odoo#117357
1. show hover effect in discuss sidebar
With redesign of web client style, hover effect in discuss sidebar
was not longer working.
This comes from buttons hover effect no longer having precedence
to defined bg classnames, e.g. `bg-100`.
This commit fixes the issue by explicitly defining a style for the
background when hovering items in the discuss sidebar.
2. improved background color of discuss app in dark mode
The background color was too dark. This commit fixes the issue by
using `bg-view`, which is the preferred background to put
content in both white and dark theme.
3. Send button visual matches composer rounded border
Send button lacked its border. This commit fixes the issue by
including Send button inside the element that does the pretty rounded
border of composer. That way, the border of send button will not
longer be affected by change of button style.
Also make the send button active / inactive state more visible, by
using button link (green when active, muted when inactive).
Part-of: odoo/odoo#117357
1. Display avatar in top bar next to channel name and description.
2. Edit icon appears on hover.
3. Clicking on the Edit icon opens file browser to upload a new avatar.
4. Certain file types are allowed.
5. Avatar can only be changed for group chat by any member of the channel.
6. For channel it can be done with admin rights.
7. Disable uploading text from file uploader in this case.
Also show avatar of channel/chat conversation in chat window.
Author avatar in message list no longer shown im status.
Chat window header color matches new systray color.
task-2684679
[FIX] mail: make chat window header match systray color
Part-of: odoo/odoo#117357
Before this commit, when the user is colorblind and sees the kanban
view of project.task, he cannot see the difference between
`Changes Requested` and `Approved` options and so he has to
alternatively open the form view to make sure that they are reading
it right because no check mark appeared in the dropdown to know
the current option selected.
This commit changes the icon of `Changes Requested` state option and
also adds the check mark in the dropdown options of the state field
to show which option is the current one.
task-3287326
closesodoo/odoo#121427
X-original-commit: 5e477356d2498cb0692f869053531082b4e7618f
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Step to reproduce:
1. Set up Cash rounding for Tax: Accounting> Configuration > cash
rounding
2. Set up recurrent product: Service type - Prepaid - tax VAT 7.7
3. Create an order with that product - set price of 45 (to have the
rounding) > confirm order > Create an invoice
4. In the new invoice > "Other info" tab > add the rounding method
5. Change the quantity
Current behavior: tax doesn't update if there is a rounding line
Expected: tax should be updated.
Why:
What happens is that odoo trying to update the new tax amount on the
wrong line (the rounded tax amount line).
That's because the `existing_after` dict is poorly defined. It is
defined by the `existing()` inner function of `_sync_dynamic_line`
thanks to the "tax_key" of each line.
The two account move lines (VAT line and rounding on the VAT line) share
the same tax_key, and because of that the VAT line is overwritten by
the rounding line in the dict returned by`existing()`.
Then the cash rounding is recomputed from the VAT line(that still holds
the outdated values) and overwrites the updated values on the rounding
line.
Solution:
Adding the type of line in the tax_key to differentiate between a VAT
line and a rounding VAT line
opw-3224743
closesodoo/odoo#121426
X-original-commit: c27236d49d4f60940d79471e0ae66a0aed3c572d
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Sales profit tax witholds should not affect the tax report 103, it should be empty
closesodoo/odoo#121317
X-original-commit: 2dd8dd999b93dafdee5054beb71a7348eaec4eb9
Signed-off-by: Josse Colpaert <jco@odoo.com>
To Reproduce
============
- create two Vendor Bills and attach to each one a PDF from the ones
provided by the client on the ticket.
- select these two bills and and try to print Original Bills an error will be raised
Problem
=======
while merging these PDFs, PyPDF2 throws a `TypeError` which is not caught by the server
Solution
========
catch `TypeError` to raise a UserError
opw-3285540
closesodoo/odoo#121313
X-original-commit: 5053620c640136025f5b37c5b8d233ad63825389
Signed-off-by: abla001 <abla@odoo.com>
When inside an HttpCase, the end of a successful request will
`signal_changes` meaning that the registry_invalidated flag is removed.
A second issue is that this flag is thread local meaning that if a
request set the flag, it won't be visible from the test thread.
For those reasons, this commit ensures the registry sequences are
incremented as in production mode, and adds a check that the sequence
didn't change during the tests, calling `setup_models` the registry
manually if needed.
closesodoo/odoo#121268
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Step:
- Create a product with sale price 120 USD
- Create a giftcard with balance 40 uSD
- Create a free Shipping cost of 40 USD fixed price and freeing above 100 USD
- Go to website->shop, select the product and checkout the cart(the shipping is free because price exceeds 100)
- Add the gift card to payment
Issue:
The shipping price gets from free to 40
Cause:
When computing the cost of the shipping the fact of the presence of a giftcard is not considered.
Solution:
Create a method to returns the amount of giftcard from a sale order and add to total price to check if the shipping is free
opw-3107284
closesodoo/odoo#120174
X-original-commit: c57184fd1c3d2846df4f618dee0027364eb62596
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Djoumatchoua Eteil Junior (etdj) <etdj@odoo.com>
- Unable to do global discounts because the `Discount` product isn't
`Available in PoS`. The available in pos paramater of the `Discount`
product in the data has then been set to true.
- The attribute `tip_product_id` gets as default the product of default_code TIPS.
- The condition of the display of tips option in pos payement has been
changed to the boolean corresponding to the tick box of the settings and
the `tip_product_id`.
- Before, if a tip product was set and the tips
option in the setting unselected the tips was still availible in the pos
payement since it was based on the tip product id and not on the tick
box. However, the `tip_product_id` still remains in the condition since
it can be possible to check the option and not select a tip product.
Task-3283007
closesodoo/odoo#119324
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When the user configures PayPal/Alipay and in his PayPal/Alipay account he set
the IPN address to the webhook_url he receives a notification from PayPal/Alipay
with data. Then origin of that notification is checked and when PayPal/Alipay
sends 'invalid'/'false' as a response the error occurs.
To fix this issue the log is updated into a warning.
sentry-4116633764
closesodoo/odoo#121476
X-original-commit: 100f2526e91d781a01d959d08dc0ccfae4389061
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Saurabh Choraria (sauc) <sauc@odoo.com>
Allow extending tests for any modules, regardless of existing ones
in another entry of the `upgrade-path`.
Bonus point: tests no longer need to be imported in the `__init__.py`
file.
closesodoo/odoo#121453
X-original-commit: ed1b27dbdfc0a5084051c59da9c4578262b3bf8c
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Alvaro Fuentes <afu@odoo.com>
Currently, when a specific capacity is defined for a product in a
workcenter, if a setup / cleanup time is given, it will be added to the
existing setup / cleanup time of the workcenter.
What we want instead is to be able to fully define what the
setup/cleanup time is for this specific product. So the given times in
the specific capacity override the times defined in the workcenter for
that specific product.
To help with that, we set the workcenter's setup/cleanup time as a
default for their related specific capacities, since if not changed,
they will follow the workcenter times.
Updated the tests so their specified capacities match the new behaviour.
closesodoo/odoo#119212
Related: odoo/upgrade#4576
Signed-off-by: Tiffany Chang <tic@odoo.com>
In 14.0 the menu items in the navbar sections menu could have any level.
Since the webclient refactoring landed in 15.0 0573aca this feature has
been unintentionnally limited to two levels.
More sub menus would simply not be displayed.
**Before this commit**
- Have a menu item with the following path:
`App/Menu/Group/Sub-group/Item`
- The `Sub-group` is displayed as an item. It is clickable but nothing happens.
- The `Item` is not displayed.
**After this commit**
Works properly as it should. See screenshots on the PR description.
closesodoo/odoo#121422
X-original-commit: 708d17ba3a9d12e153069ecb7ae6c8e3d6187dd0
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, the moved tours were added to the common and
frontend bundles, and were thus loaded all the time even though
they only exist for testing purposes.
This commit moves the two files to the correct bundle.
closesodoo/odoo#121408
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This test has been adapted by the milk PR, but it only passed with
all modules installed, because it relied on some items added to the
action menu. This commit makes it more robust by changing the
selector to target the "Delete" item.
closesodoo/odoo#121435
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
The test test_04_pl_reset_on_login is failling determinstically
when run on a database with only `website_sale` installed, or in
some specific branches/setup (e.g. l10n nightly tests)
This commit makes sure the test works fine when only website_sale
is installed and also restricts more the test environment to make
sure data from other modules does not impact its behavior.
Finetuning of a9339c24591e4fcfe86f457accabb43050d2fe27
closesodoo/odoo#121428
X-original-commit: 929d71ccb6f180903fd30d53eeb627f2d81f5c7a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Bug:
When the `sale_loyalty_taxcloud` is installed and 'Lock Confirmed Sales'
is enabled, confirming a SO impossible.
Setup:
- install `sale_management` and `sale_loyalty_taxcloud`
- activate Taxcloud (with test credentials)
- enable 'Lock Confirmed Sales' in the settings
Steps to reproduce:
- create a quotation, fill the necessary fields and add a product
- in the 'Other Info' tab, set the fiscal position to
'Automatic Tax Mapping (TaxCloud)'
- attempt to confirm the quotation
You should be met with a message stating that you can't modify the tax
on a locked order.
Cause:
This issue was introduced by odoo/enterprise@ea954b818b
Enterprise PR: odoo/enterprise#40880
opw-3289657
closesodoo/odoo#121410
X-original-commit: d676498902adf2dcd8fa4530fc21e84fb940aad2
Related: odoo/enterprise#41060
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Prior to this commit, `o_navbar` wasn't fully hidden when we were in
edit mode and created an offset at the top of the loader when we loaded
something (eg. changing the header template).
This commit fixes this issue.
task-3326604
Part of task-3326263
closesodoo/odoo#121387
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
sale_product_configurator: not store product no variant attribute value
on the sale order line if there is a single product attribute value on
the product template attribute line.
Before this change, product no variant attribute values were not
displayed on the sale order line if there was only one product attribute
variant on the product template attribute line. This behavior was
altered in 7e42f381c3 when product configurators were migrated to Owl.
This commit ensures that when there is a single product attribute
variant on the product template attribute line, product no variant
attribute values are not displayed on the sale order line.
closesodoo/odoo#121265
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
The cookie policy banner template includes nested selectors, such as
o_cookies_bar_text_policy within o_cookies_bar_text_secondary.
The process for switching the banner layout involves copying selectors
based on the order defined in CookiesBar::selectLayout()::selectorsToKeep.
However, a bug caused o_cookies_bar_text_policy to be copied before
o_cookies_bar_text_secondary, resulting in its content being overridden
by its parent content. The fix involves reordering the selectors so that
o_cookies_bar_text_secondary is copied before o_cookies_bar_text_policy.
opw-3302511
closesodoo/odoo#121324
X-original-commit: 720ae005bce261ce3b9e32dc8ade1f1d97f1aee1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Prior to this commit, after [1], when a user is trying to visit or view
their website from a domain that is not their current website, a
traceback would appear if the redirect took too long.
This is because when redirecting, we do not set any URL as the iframe
iframe source, so it loads the `about:blank` page. When trying to push
that page into the history (done to change the name and url displayed in
the browser), the browser crashes and displays a CORS error.
On top of that, it seems some users do not understand what is happening
and feel like they are being logged out if they're not logged into their
custom domains.
This commit prevents replacing the history state if the page displayed
in the iframe is `about:blank`.
It also displays a dialog before redirecting, explaining to the user why
it is necessary.
Steps to reproduce:
- Go to website settings
- Set a domain for your website that's different from the one you are
currently using to access Odoo (Could be anything but for a realistic
setup, if accessing from localhost, use 127.0.0.1 or the other way
around, or use different 127.0.0.X ips)
- Toggle a slow network mode from your browser's dev tools
(This is to ensure the traceback appears as it does not if the network
is quick enough with its redirect)
- Go on the website app
=> A traceback appears (and disappears as the page is unloaded)
[1]: https://github.com/odoo/odoo/commit/59b96b0742fe8da31eecf896f7a6157811d49de5
opw-3250663
closesodoo/odoo#121311
X-original-commit: 15a31cbcec9f51c72abac8df69932cc1a742baef
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Prior to this commit, starting this test individually would not work as
the admin user is subscribed to the mailing list used during the test.
The reason the test has passed our test suite is because on runbot the
`mass_mailing_sms` module is installed, which adds a new mailing list to
which the admin user is not subscribed.
This commit changes the test to always ensure that the admin is not
subscribed to any newsletter, making the test a bit more robust.
closesodoo/odoo#121200
X-original-commit: f7465d0f13236518ee79e43e65222d0ca0c0b0fb
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Some of the Editor methods relies on not having inline elements at
the editable root. For this reason, the cursor should never be placed
at the editable root, but always inside a block element.
Before this commit, in some situations (notably around tables and
horizontal separators), the cursor could be placed having its anchorNode
at the editable root, allowing the user to insert inlined text at it.
This commit fixes the selection range in such cases, and an empty paragraph
is inserted in cases where there would be no other way to insert text before
or after an existing block.
task-3128747
opw-3106752
Part-of: odoo/odoo#119556
Xavier Morel