Steps to reproduce the bug:
- Create a delivery picking:
- product: P1
- Qty: 10
- Mark as todo
- Set “Quantity” to = 6
- Validate the picking without creating a backorder
- return the picking
Problem:
The qty to return is 10 instead of 6
opw-3726157
closesodoo/odoo#155508
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Current behaviour before commit:
When text is selected, applying table command through
powerbox makes toolbar appear along with tablepicker.
This happens because selection is not collapsed.
Desired behaviour after commit:
Now applying table command through powerbox opens
tablepicker only.
task-3482230
closesodoo/odoo#155504
X-original-commit: d090b889f648d1f454d7af0bab828dc57b2df167
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Current behaviour before commit:
When text is selected, applying table command
through powerbox throws error.
Desired behaviour after commit:
Now when text is selected, applying table
command through powerbox creates new table
without any traceback.
task-3482230
X-original-commit: a3384f8708c07b25d092b03b671198fd6877d1d1
Part-of: odoo/odoo#155504
On the contact kanban view, add as much tags as possible. The point is to make the right hand
part of the kanban card as tall as possible.
Before this commit, the image (on the left hand side) of the individual partner was taking all the space
in the y-axis, which was on purpose, but the cropping of the image made it so that the image
lost is sense: a face was too much cropped, or, if the image did not have sufficient pixel density, it was
pixelized.
What is specific to 17 that is barely applicable in earlier versions, is the changes in the display of many2many tags
in the kanban record: they now take more space and at a faster pace.
After this commit, we constrain that image to a maximum height and centering it.
opw-3748585
opw-3751016
closesodoo/odoo#155359
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce the bug:
- In Website edit mode, drag & drop a text-image snippet onto the page.
- Click on the image of the snippet.
- In the image options, select "On Hover" for the "Animation" option.
- Click on the "Undo" button in the top bar of the editor panel.
- Bug: The "Animation" option has not been deactivated, the "Hover
Effect" is still present when hovering over the image.
task-3495241
closesodoo/odoo#134979
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
This commit adds the possibility to preview the various effects
available in the "effect" option for 'on hover' animations when hovering
over the dropdown. The sub-options of these effects are also previewed.
This commit also prevents the user from seeing the different changes
that occur to an image with a shape while changing one of its options
(e.g., changing the shape, previewing hover effects).
task-3495241
Part-of: odoo/odoo#134979
This commit makes improvements as requested in the following pull
request [1] ("allowing the ability to flip/rotate image shapes" and
"adding an 'on hover' option for animations").
It mainly focuses on refining the code for better organization.
[1]: https://github.com/odoo/odoo/pull/119197
task-3495241
Part-of: odoo/odoo#134979
Background videos' dimensions are adapted according to the screen size.
This could lead to the video not showing in RTL languages, because the
computed position was coded for LTR languages.
This commit replaces the `left` and `top` CSS properties with logical
properties to account for language directions.
Steps to reproduce:
1. Add a Cover snippet
2. Add a video to it (use any sample videos from the selector)
3. Save > Check mobile view, video shows fine.
4. Add a Right to Left language to the website (Persian, Arabic...)
5. Switch to the RTL language > Check mobile view
=> video doesn't display properly.
opw-3688660
closesodoo/odoo#155478
X-original-commit: e75ff0792376621f5335a5955ce32a54a1a5c441
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
This commit prevents the sitemap from being translated when a website is
available in multiple languages. The sitemap should always be in the
default language of the website.
Steps to reproduce the bug:
- Set up a website in English and French
- Navigate to the French version of the website (/fr)
- Access the sitemap (/sitemap.xml)
=> The sitemap appears in French but should be in English.
Note: There is a cache for the sitemap. It is not regenerated if it has
been generated within the last 12 hours (see `SITEMAP_CACHE_TIME`).
task-3743970
closesodoo/odoo#155472
X-original-commit: 809854c5d10735fb280141f5291bdb84d8d36569
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
When hr_gamification is installed, it's not possible to grant badges to
users that don't have associated employees.
Expected behavior: we should be able to grant badges to any users.
This is because user_id was related field with employee_id.
We remove that dependency.
task - 3593382
closesodoo/odoo#155007
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Commit [1] changed the behavior of `setTagName` to only carry the attributes of
paragraph related elements. Ideally, this should not carry the attributes of
`<li>` element only.
[1]: fcb3846
task-3764154
closesodoo/odoo#155448
X-original-commit: 0a47626dba4019fabaf4e399db3369b3db2e712e
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Deependra Solanki (deso) <deso@odoo.com>
Issue:
======
Invisible whitespaces at the start gets deleted by one by one with
delete forward.
Steps to reproduce the issue:
=============================
- Go to knowledge
- Add any text
- Make sure you have an empty line before it
- Change the html of the added text and add some spaces at the start
(this is the easiest way to reproduce it)
- Go to the line before and keep deleting forward
- The invisible spaces will be deleted one by one.
Solution:
=========
When the selection is at the start of the node and it contains
whitespaces, `parentState` whill have undefined node when deleting
forward since we are at the first leaf. We need to keep deleting forward
with the text node instead of parentElement because calling delete
forward with the parent will do a 1 delete backward call from the
specified offset and it will not propagate forward anymore.
task-3629743
closesodoo/odoo#155435
X-original-commit: 6cfe30b1f194f7c53e8f91dde3251d7ba327ec56
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Issue:
======
Delete forward on emoji dosn't work
Steps to reproduce the issue:
=============================
- Go to knowledge
- Add an emoji and put the cursor on the left of the emoji and delete
forward
- only half of the emoji gets deleted
Solution:
=========
We need to get the correct offset and correct charsize because not all
of the items of the sliced string had char size equal to `1`. So we
slice the string and get the offset corrosponding to the target offset
and of course we need to handle the directions differently
task-3629743
X-original-commit: 80a5b41b85c7f6732407bec80c8e6117ae795333
Part-of: odoo/odoo#155435
Before this commit, when a salesman user without any access in other
apps (just has the `sales_team.group_sale_salesman` group) creates
an SO and adds a SOL for a product with `expense_policy='sales_price'`
and then confirm the SO, he will got a traceback because he does not
have access to `analytic.account.line` model. The reason is because
an analytic account has to be generated for the SO since there is an
expense product in its SOLs and so during the generated of analytic
account a check is triggered to be sure the company set on that
analytic account is correct.
This commit adds a sudo before calling the search method in
`analytic.account.line` model to do the check without checking
the access right since the user does not really want to read the
analytic account line.
Steps to reproduce
==================
1. Log in as Salesman user (without other access)
2. Create a product and the expense policy to Sales price.
3. Create a SO and add a SOL with that product
4. Confirm the SO
Expected Behavior
=================
The SO should be confirmed without any issue (and an analytic account
should set on that SO)
Actual Behavior
===============
Traceback is occured because the user cannot access to
`analytic.account.line` model.
Follow-up task-3256865
closesodoo/odoo#155238
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
for model_terms translated fields, for sake of typo fixing feature
if a term is removed after write its translations might be reused by another
close term which has totally different meaning
this fix removes the typo fixing if the matched closest term exists before write
closesodoo/odoo#155476
X-original-commit: 38ec36e9b5dde0c02a4ff47714b1056e0db76812
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
Steps to reproduce
* Create a new SO
* Add a new line with a storable product and 15.12 as quantity
* change the price to X
* Save and confirm
* Set a scheduled date (Other info tab)
* Save
-> The price of the SOL is recomputed.
Cause
Because of floating point issues, the value returned by the onchange for
the product_uom_qty field is 15.1200000....1, therefore being considered
in the client-side as having been changed by the onchange.
The value is then sent to the server on save, triggering a recomputation
of the SOL prices.
Until there is a clear solution in the framework, this commit drops
'unmodified values' for the product_uom_qty field, only if there is
one updated line in the write call.
opw-3670318
closesodoo/odoo#155392
X-original-commit: ef1b59062266ee4ab58b5330ce0012dcee69f2b7
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The pot file of the base module hasn't been updated in some time.
This commit takes care of that.
closesodoo/odoo#155375
Related: odoo/enterprise#57503
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Commit [1] introduced a way to copy translations from a (view) record to another (snippets to their real life use).
The core function that was implemented is the low level `ir.ui.view:_copy_field_terms_translations`. However, that function
did not support inputting a hierarchy of views.
Indeed, since translations are stored on the view record, each view that is part of an inheritance tree has its own translations.
So, to copy the resulting translation of an inheritance tree to a record that contains all the tree in itself, as it is the case in web_studio's ReportEditor since commit [2], there was a need for that method to support the input of a record set of potentially many records.
Hence this commit proposes to modify that method that now takes a record set of potentially many records as input and
still copies to a single record.
opw-3746922
opw-3724701
opw-3719157
[1]: cfc90c0b2f30c9e5b6aae29958997298196ee952
[2]: odoo/enterprise@b7d0d3034dclosesodoo/odoo#155346
X-original-commit: 2d58b1c65be65297cb17818c0c21dbf2b84b664b
Related: odoo/enterprise#57490
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Fix a bug introduced by 67901a4429c69fbba96c32af5d8f58aff54f0be5
When an expense is submitted and for the steps after, there is no need
to recompute the product_cost as it may be confusing
or generate discrepancies with the account move by changing the totals.
task-3580004
closesodoo/odoo#155277
X-original-commit: 2427ac03806205f45084640c301b3dfb9011c22c
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Steps to reproduce the issue:
- Install `website_event_sale` module
- Create an event with a paid ticket
- Go to website and register for the event for 2 persons
- Go to the cart and remove one of the attendees
- Proceed to checkout and confirm the order
- On the checkout confirmation page, click on `Download tickets`
- Open the downloaded PDF file
Issue:
Two tickets are displayed in the PDF file.
Cause:
Not filtering out the canceled attendees.
Solution:
Display tickets only for `Attended` and `Registered` attendees.
opw-3718542
closesodoo/odoo#155125
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Steps to reproduce:
- Create two companies:
(ex. Daughter Company)
(ex. Mother Company)
- Install Inventory app
- In the settings of both companies:
- enable Multi-Step Routes
- enable Dropshipping option
- Using the Daughter Company, go to Routes > Dropship route
- When You try to set Company to Daughter Company, it's possible to do so even thought the rules belonging to the Dropship route belongs to two companies: Daughter Company and Mother Company which is not consistant
Disscuss
- We constraint the route company to always be consistant with the rule(s) company and vice verca
opw-3648535
closesodoo/odoo#154403
X-original-commit: 0bc6057d986304a75ec0ba64141c965d9275f2f6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
Versions
--------
- 17.0+
Steps
-----
1. Create a new company;
2. switch to it via the selector;
3. create a new product specific to the company;
4. create a sale order;
5. open the catalog via a sale order line.
Issue
-----
Access error
Cause
-----
The catalog controller does not receive the user context,
therefore fallbacking on the default user context, with
the main company of the user. Accessing a product from
another company will fail and raise an AccessError.
Solution
--------
Make sure that catalog requests are done in the company of the
order, the information is available and it makes no sense to
use another company for those requests anyway.
Also adds the missing license in the catalog mixin.
opw-3690226
closesodoo/odoo#153915
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since PR [1], which redesigned the headers, there are now two navbars:
one for the desktop view and one for the mobile view. This also means
that the different menus are in both navbars at the same time. However,
this causes some issues with the mega menus.
Indeed, since each mega menu is in both navbars, the changes made in one
are also made in the other (since it is a field in the database). This
causes issues when drag and dropping:
- Drag and drop a mega menu element.
- Re-drag it and drop it somewhere else.
=> We notice that the element was cloned and each drag and drop adds a
new clone. Moreover, when clicking on a link inside these elements, a
traceback appears.
This happens because since both mega menus are synced, the drag and drop
clones are also synced and so the dragged element is dropped multiple
times (after each clone).
This commit fixes these synchronization issues by adding the mega menus
only once in the DOM, in the desktop navbar. They are then moved from
one navbar to the other when we open them.
[1]: https://github.com/odoo/odoo/pull/119650
task-3609531
opw-3730165
closesodoo/odoo#146492
Related: odoo/design-themes#756
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The changes happening in the header often break the history, because a
lot of them add steps in it while they should not be observed at all.
This results in losing the redo history, having to click multiple times
to undo one specific change or even seeing some intermediate states that
should not be appearing, every time we interact with the header (e.g. by
opening/closing a dropdown or a burger menu, resizing or scrolling the
window).
This commit fixes these history issues by not observing some problematic
changes. Note that this commit only fixes the most "annoying" ones (i.e.
the ones that break things) that prevented the other commits of this PR
to work correctly. A second pass will be needed to remove other useless
mutations (i.e. that do not break things but should not be observed
either). This commit will also need to be backported, as these issues
are also present in earlier versions.
Here are the changes that are not observed anymore:
- When we open/close a "burger" menu (i.e. the "Hamburger menu" or in
mobile view). It was adding a step in the history, so if we opened and
closed it in the middle of a redo, we would lose the remaining "redo".
- When the extra menu is added/adapted. When resizing the window, which
also means toggling the mobile view, if there is not enough space for
all the desktop menus to be visible, they are moved in an extra ("+")
menu (they are moved out when there is enough space). This resulted in
the intermediate state where the menus are not in the extra menu yet to
be visible when undoing at some point, which did not look good.
- When hiding a dropdown by scrolling the page and hiding a hoverable
dropdown by clicking somewhere on the page. When they are hidden this
way, undoing the change that will be done after that would reopen the
dropdown, which could be annoying if the dropdown was a mega menu for
example.
- When showing a hoverable dropdown. This added a step in the history,
and since opening a "clickable" dropdown does not do it, this also
should not be the case for a hoverable one.
task-3609531
opw-3730165
Part-of: odoo/odoo#146492
With the headers redesign in PR [1], the "collapse menus" (e.g. in the
"Hamburger menu" and the mobile menu) are now `Offcanvas` elements
instead of `Collapse` elements (see `data-bs-toggle="offcanvas"` in the
headers XML templates). As such, when they are toggled, it is now
`bs.offcanvas` events that are fired, instead of `bs.collapse`.
However, the code using these elements and handling these events has not
been adapted and is therefore never executed, which causes some issues.
1) First issue:
- In edit mode, drop enough snippets to have a scroll bar.
- Toggle the mobile preview and open the menu or resize the screen so it
is smaller than the `SM` screen breakpoint.
- With the menu still open, go back to the desktop view or resize it up
beyond the `SM` breakpoint.
=> There is no scrollbar anymore so we cannot scroll.
This happens because the selectors and event listeners managing the
collapse menus and the scroll do not target the right elements/events.
- On toggle, the `overflow-hidden` class should be added on the body to
prevent the scroll.
- On hide, this class should be removed to re-allow scrolling.
=> Here the scroll is prevented by chance thanks to commit [2] but it is
not the right flow.
- On resize, when the screen becomes bigger than `SM`, the collapse menu
should be closed and the `overflow-hidden` class removed from the body
(see the `_updateHeaderOnResize` function).
=> Not happening because the collapse menu selector is not the right one
and commit [2] does not take the resizing into account.
2) Second issue:
- Change the menu to "Hamburger menu".
- Set the background to a dark color (so that the text is white).
- Set the "Header Position" option to "Over The Content".
- Open the menu.
=> The menu is still considered as transparent so the text is dark on a
dark background, making it difficult to read.
This issue was originally fixed by commit [3], by adding the `o_top_menu
_collapse_shown` class when the menu is opened. It happens again because
since the event is not the right one anymore, the class is never added.
This commit adapts the menus public widgets code in order to consider
these `Offcanvas` elements/events and restore the needed behaviors.
Note that the `NavbarDropdown` public widget (added in commit [4]) is
now useless. Indeed, it was added in order to prevent the dropdowns to
be hidden when opened inside a burger menu, but this issue does not
happen anymore when following the steps. It has already been removed in
master by commit [5].
The same goes for the `TopMenuCollapse` public widget, which was added
in commit [6] to avoid having a scrollbar when opening a sub-menu after
resizing up the screen with the mobile menu open. It is not even started
because its selector is not valid anymore (the `top_menu_collapse` id
only exists in the "Hamburger menu", where the issue cannot happen), and
the issue is not there anymore when following the steps, which makes the
widget useless. It will be removed in master.
[1]: https://github.com/odoo/odoo/pull/119650
[2]: https://github.com/odoo/odoo/commit/f6d9f80e6e8458bdcf75fca9ff3b7e7e54d2a6ba
[3]: https://github.com/odoo/odoo/commit/e10913daf7025accb3b93808ae12ce4a50db1510
[4]: https://github.com/odoo/odoo/commit/ce9b350403ff7c1004b50b39588891ee652e0a3a
[5]: https://github.com/odoo/odoo/commit/39b79832a0cd3e191077a11a485de78365928feb
[6]: https://github.com/odoo/odoo/commit/b7a4538c51aacca666920bdd9496ee575ab12e7a
task-3609531
Part-of: odoo/odoo#146492
*: test_website_modules
In PR [1], the headers have been redesigned. One of their major changes
is that now, they have two navbars: one for the desktop view and one for
the mobile view.
However, the `o_main_nav` and `top_menu` navbar ids are also duplicated,
meaning that there are multiple elements with the same id in the DOM,
which is not a good practice.
This commit fixes this by replacing the ids by classes in the navbar
templates, since their use does not really require for them to be ids
(e.g. `#o_main_nav` is mainly for styling). For the desktop view, the
ids are still kept (for stability purpose).
Note that the CSS rules and the selectors in the JS files (except for
the tests) now take into account both the ids and the classes (to be
safe).
[1]: https://github.com/odoo/odoo/pull/119650
task-3609531
Part-of: odoo/odoo#146492
Current Behavior:
The word "Discount" is translated in the users language unlike the
content of the description which is translated into the customer's
language
Expected behavior:
The word "Discount" should be translated as the content of the
description.
Steps to reproduce:
Sales > Product > Discount & Loyalty
Create a new loyalty program and add a translation to the reward
description.
Create a SO for a customer with the same language. Add products to
meet the requirements of the loyalty program and click on
Promotion.
A line is created for the reward, but the word "Discount" is not
translated into the customer's language, but the rest of the
description is.
Cause of the issue:
The translation of the word Discount is done inside a dictionary
comprehension using the _ = GettextAlias() method.
As a result, 'self' does not appear in the arguments from which _
guesses the contextual language. Therefore, the language in which the
translation happens is the contextual language of the request (user).
Fix:
The translation is applied before the discionary comprehension so that
the method "_" correctly guesses the contextual language.
opw-3700429
closesodoo/odoo#155296
X-original-commit: 03cbf7238400130c412a1606b6a9a2f22725e590
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit:
- In the fullscreen player, the content of an article from any course stuck to
the contents sidebar, leading to a lack of visual separation.
After this commit:
- Added padding to the article content in fullscreen view. Creating a clear
distinction between the content and the sidebar.
Task-3748836
closesodoo/odoo#155207
X-original-commit: ebb86b65acc2cf59fd3272f56054c00b161fe9aa
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Signed-off-by: Shubham Thanki (shut) <shut@odoo.com>
Prior to this commit, the receipt element was cloned and appended to
the render-container for web printing, then deleted after print
callback. This approach failed on Android, leading to an empty page,
as the cloned element was removed before printing. This commit resolves
the issue by retaining the cloned element until the next clone addition
to the container, at which point existing elements are removed.
opw-3755682
closesodoo/odoo#154777
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Ease understanding the purpose of main fields on alias domains. Set bounce,
catchall and default_from available in debug mode as those are advanced
configuration bits that should be displayed (and modified) with care.
Add tooltips on fields to ease understanding the field usage.
Task-3696224
closesodoo/odoo#150401
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
During the revamp (https://github.com/odoo/odoo/pull/138670) the
classes `.o_event_hatched` and `.o_event_striked` were moved.
The `o_event_hatched` works on day, week, and month
view but not in Year view of the `hr_holidays` module where the events
all look like they have the same status. The `o_event_striked`
was removed by mistake.
To fix this issue, we move the `.o_event_hatched` where it isn't under
the `.fc-event` selector (because this one doesn't exist in Year view),
and we put back `o_event_striked`.
task-3617333
part of task-3575827
closesodoo/odoo#144208
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
A character was left out of the translation pattern, so the text was
never displayed correctly to the user.
closesodoo/odoo#155331
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Following commit ac90aa07, the Customer object was no longer created on
Stripe for one-shot (non-recurring) payments made with Stripe. This
prevented Radar (Stripe's fraud detection tool) to work effectively as
it could not rely on the customer's name and addresses anymore (see
https://docs.stripe.com/radar/integration#recommendations).
This commit forces the creation of a Customer object even for one-shot
payments.
opw-3694379
closesodoo/odoo#155276
X-original-commit: 20efda51fefcc50861d9c73a483b4291e5b7e85d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Since https://github.com/odoo/odoo/commit/a54c304487429139c08f384d7b2b620b50cf6f83, sale_loyalty_delivery does not depend on stock anymore.
So, the type 'product' (and detailed_type) is not added to the selection.
The test does not fail on runbot because the module is never tested alone.
We should just change it to type 'consu'.
closesodoo/odoo#155263
X-original-commit: 88ebd8918c0ffdd9ae784967fe0de42a9299e09a
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
It is necessary to force the definition of a namespace in the string type,
as it may come from an external context.
See odoo/odoo@13af401bc2
opw-3767015
Signed-off-by: Christophe Matthieu (chm) <chm@odoo.com>
In some scenarios, it is necessary to evaluate the representation
of fields as a string (which triggers issues if this is not the case).
closesodoo/odoo#155299
X-original-commit: e89b47f44548170abff088427149337411fcc47b
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Commit [1] introduced some code that relied on a cache we currently have
for processed** images. In case of 404, that cache is not filled... and
relying on it thus crashes.
This commit circles around the issue by taking profit of [2] which now
forces `loadImage` to load a placeholder image in case of a 404. This
makes sure that in case of a 404 during the initial call to `loadImage`,
the rest of the stack works with the loaded placeholder image.
**Note: the current cache is not filled at the `loadImage` level, but
later when processing the fetched image. This should be changed in the
future (a task has been created).
See [3] and [4] which are example of unwanted 404 images due to other
issues, which allowed to discover this bug to fix here.
Steps to reproduce:
- Go on the `website.s_picture_default_image` ir.attachment form view
- Change the URL value to a relative path that does not exist
- Go on a website page and edit
- Drop the "Picture" snippet => Crash
=> After this fix, no crash but you can also edit the image if you were
able to click on it, it would use the placeholder image as source.
[1]: https://github.com/odoo/odoo/commit/567e5b58d544e4e56c3a68d148e862a516d77c4f
[2]: https://github.com/odoo/odoo/commit/0639c5028c69d8e29c8438b741cc4713d875b06d
[3]: https://github.com/odoo/odoo/pull/155015
[4]: https://github.com/odoo/design-themes/pull/767
Related to opw-3693055 and others (see [3] and [4]).
closesodoo/odoo#155275
X-original-commit: fbc6a697c1adf67ee8a90c49b0150d6ca170e081
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- In User settings add 'allocation reports' group to the admin User
- In Inventory settings enable allocation reports
- Create a stored product with 0/0 reordering rules and set a vendor
- Create an SO for that product
- Confirm the generated PO and click assign all on its receipt's allocation report
- Reduce the quantity on the SO and save
Bug:
a return is created instead of adjusting the quantity to deliver
the stock moves were not merged because their procurement method do not
match ('make_to_stock' / 'make_to_order')
Fix:
ignore procurement method when merging the moves
(introducing new config parameter)
opw-3621316
closesodoo/odoo#154942
X-original-commit: 337d4c79bf51f0d1705a80341fa83a88c5297128
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
When l10n_pe was initially developed, there were two unresolved matters that needed clarification for the users. However, with this recent commit, the manifest has been cleaned up, and now the explanation of the module is much clearer and easily understandable for the users.”
closesodoo/odoo#155321
X-original-commit: 86f4a3dcae0f171327c8527df974b406920da3f8
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to reproduce
------------------
* install `l10n_sa_edi`
* switch to a Saudi company
* deactivate the "EDI : Perform web services operations" scheduled
action. (this will help ease the reproduction process)
* create and post two invoices for a partner that's an individual (not a
company)
* manually run that scheduled action.
You should be met with a traceback.
Cause
-----
When a ZATCA document is submitted, the system performs several
operations, two of which are important for this issue:
1. Generating a signature (`l10n_sa_invoice_signature`)
2. Using this signature to generate a QR code (`l10n_sa_qr_code_str`)
The QR code generation relies on the assumption that the signature
(`l10n_sa_invoice_signature`) already exists, which is a reasonable
expectation as the signature is typically created prior to the QR code.
However, complications arise when multiple documents are submitted
simultaneously in a batch process. During batch processing, each
document in the batch undergoes the same two operations mentioned above.
The issue emerges due to the behavior of non-stored computed fields .
In Odoo, computed fields are evaluated in batches, meaning that if you
access a computed field for one record, Odoo may also compute the same
field for other records fetched in the same operation. For example, if
you have two records, `A` and `B` such that `B.id in A._prefetch_ids`,
and you access a computed field on `A`, Odoo will also compute this
field for `B` at the same time.
This behavior leads to an issue when submitting two documents (`D1` and
`D2`) together. The system will generate a signature and then compute
the QR code for `D1`. However, when computing the QR code for `D1`, it
inadvertently attempts to also compute the QR code for `D2` due to the
batch computation behavior. Since `D2`'s signature has not yet been
generated at this point, this results in an error.
opw-3696146
closesodoo/odoo#155269
X-original-commit: 97e67514c0e72730882cc093b36cb5477eba496d
Signed-off-by: William André (wan) <wan@odoo.com>
Cascade removal of account.report.expression records to corresponding
account.report.external.value, avoiding the following issue when upgrading:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1302, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 536, in load_modules
env['ir.model.data']._process_end(processed_modules)
File "/tmp/tmpwrjjshgf/migrations/base/0.0.0/pre-models-no-model-data-delete.py", line 103, in _process_end
return super(IrModelData, self)._process_end(modules)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2562, in _process_end
self._process_end_unlink_record(record)
File "/home/odoo/src/odoo/17.0/addons/website/models/ir_model_data.py", line 36, in _process_end_unlink_record
return super()._process_end_unlink_record(record)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2491, in _process_end_unlink_record
record.unlink()
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4218, in unlink
cr.execute(SQL(
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.ForeignKeyViolation: update or delete on table "account_report_expression" violates foreign key constraint "account_report_external_value_target_report_expression_id_fkey" on table "account_report_external_value"
DETAIL: Key (id)=(94) is still referenced from table "account_report_external_value".
```
closesodoo/odoo#155242
X-original-commit: d28ae22e08c86392f3d772d3d7564b1b8e70e7e0
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
This commit backports the test introduced in odoo/odoo#155154, as
it is relevant to have it in every versions to ensure that dropdown
menu (i.e. submenus) are correctly tested.
closesodoo/odoo#155218
X-original-commit: 8915c8db63d2ebc697bbfc073e3504589a26b4b8
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The following combinations of payment methods and providers are removed:
- Amazon Pay - Adyen: The payment method cannot be activated because it
requires saving a public key in Odoo, and no field was made available
for that. Also, a custom configuration is necessary and the public key
must be generated through a lengthy process that is too cumbersome for
the added value of the payment method anyway.
- BLIK - Stripe: The payment method is not supported by Stripe when the
PaymentIntent object is created after collecting the payment details.
See https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=payment#enable-payment-methods
opw-3736511
closesodoo/odoo#153481
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When creating a SOL on the fly, if the name entered matches an existing service product, selecting 'Create' should create the SOL without opening a form view modal.
We do that by fetching the `default_name` from the context.
However, from the Many2one field, since the name will already be present in the create vals, in will not be in the default values in the context.
To fix this, this commit adds a new context key when calling `name_create` that allows us to retrieve the name from the `default_get`
Task-3553151
closesodoo/odoo#155191
Related: odoo/enterprise#57344
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Vincent Larcin (vila) <vila@odoo.com>
When creating SOLs on the fly in the employee mapping on projects, only the "Create and Edit" option is available.
This commit enables the quick create for SOLs in the mapping.
Task-3553151
Part-of: odoo/odoo#155191
When the user creates a new record having a property field, the system
fetches the property definition of the parent record to retrieve the
field's default values (see: `_add_default_values`). If the user lacks
read access on the parent record, the user gets an access error when
retrieving the property definition of the parent record.
To prevent this error, we will perform a sudo call on the parent record
before reading the property definition of the parent record. This allow
the user to create a new record, even if they do not have access to the
parent record.
task-3594814
closesodoo/odoo#155178
X-original-commit: 6f0fb8579d8230f91b7eefc5d29f8d61390dacc4
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Julien Banken (jbn) <jbn@odoo.com>
Before this commit, validation transactions would send an email when the
token is assigned to the order.
closesodoo/odoo#155167
Taskid: 3675875
X-original-commit: f70967e240058d8a6b095fc58c591249e517bd31
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Djamel Touati