When installing the Odoo Debian package on Bookworm, under certain
conditions, the following bug may arise:
`Warn: Can't find .pfb for face 'Times-Roman'`
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059326
As this bug is not yet fixed on the Debian side, this commit is a
workaround.
closesodoo/odoo#154017
X-original-commit: 70e192137e9b603c502aea878313cd7611fe0337
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Steps to reproduce:
- Install `event_crm` module
- Create an Event with a company
- Go to `Events > Configuration > Event Lead Rules`
- Create a new rule and set no company
- Try to set the event created above for Event field
Issue:
Event created not displayed as possible value for the Event field.
Cause:
Because we have `check_company=True` set on `event_id` field, the
field will be filtered based on the `company_id` field, and since no
company is set on the rule, events with company will not be listed.
Commit that introduced the issue: https://github.com/odoo/odoo/commit/0479b2b59466ae1d6d74165345aa3a7dc5de24ed
Solution:
Revert to the previous behavior (remove `check_company=True` from
`event_id` field and use a domain instead).
opw-3715864
closesodoo/odoo#154009
X-original-commit: 13cb20dafb6dd473fe71b605a2adf70fa0ac368e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- Switch to a language where removal strategy name is translated
(FR in 17.0)
- Edit product category and set a translated removal strategy
- Update on hand quantity
Bug:
User error removal strategy not implemented
the removal strategy name is used in the code to identify them
when changing the name through translation it is not recognized anymore
Fix:
use the untranslated term when checking the strategy type
opw-3697462
closesodoo/odoo#153970
X-original-commit: 210f0d1c56dab45b2a00f86e1c7d836f558e6feb
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Desired behavior after PR is merged:
Enhancing the job posting with an XML tag for the title of the position so it can be used for the google rich search.
opw-3713519
closesodoo/odoo#153682
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Since PR #137969, the `save` button is no longer available in schedule activity
wizard.
This PR makes `schedule` button available for call activities like other
activities (except meeting), so user can create a call activity without going to
calendar view.
Also, we have to consider `has_error` in creating activity so if there is an
error, user couldn't access to `schedule` button. This field is correctly placed
in `mail.mail_activity_schedule_view_form` view but not in the inherited view
in `calendar`.
task-3668732
closesodoo/odoo#152893
Signed-off-by: Maryam Kia (maki) <maki@odoo.com>
Steps to reproduce
==================
- Install account_accountant
- Go to settings
- Enable Budget Management
- Go to Accounting > Reporting > Management > Budgets Analysis
- Switch to the graph view
- Change the measure to "Planned amount" and then back to
"Practical amount"
=> The practical_amount measure is undefined,
The theoritical_amount measure is missing.
Cause of the issue
==================
The view is defined as follows:
```xml
<graph string="Budget Lines" sample="1">
<field name="crossovered_budget_id" type="row"/>
<field name="planned_amount" type="measure" string="Planned amount"/>
<field name="theoritical_amount" type="measure" string="Theoretical amount"/>
<field name="practical_amount" type="measure" string="Practical amount"/>
</graph>
```
The theoritical_amount and practical_amount are non stored fields and
thus are skipped inside `computeReportMeasures` unless they are passed
in `activeMeasures | additionalMeasures`. [0]
When parsing the graph view, the last field of type measure is
passed to the graph model and is the one that will be used initially. [1]
This is why the practical_amount is initially defined.
Solution
========
We simply need to keep track of fields of type measure.
This was the case in 14.0 but got lost in the conversion.
---
[0]: https://github.com/odoo/odoo/blob/e7a9ebec3176c37485643fcda2381e489a1df86f/addons/web/static/src/views/helpers/utils.js#L49-L60
[1]: https://github.com/odoo/odoo/blob/0fb64bef16914937cf4a1d1618fb58ade6d16f14/addons/web/static/src/views/graph/graph_arch_parser.js#L63
opw-3713613
closesodoo/odoo#153967
X-original-commit: 76178cd61ba10ff29b24183edb550c54b319a230
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
This fixes a bug where trying to set the default name value
of an expense report when created from the expense tree view
would traceback.
Step to reproduce:
- Create 2+ new expenses having the same payment_mode
(E.G. 'own_account')
- Clear the date field of an expense so at least one of the expense
has a date and one has no date
- Press the 'Create Report' button on the expense tree view
Current behaviour:
Traceback due to bool > Date comparison
Expected behaviour:
We fallback to a default name when two sheets are created.
We do not set a name when only one shert is created.
task-3725176
closesodoo/odoo#153943
X-original-commit: ddb3b825a7bec28975052f858ea1512a7cf16f08
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Steps to reproduce the bugs:
- Install the e-commerce on your website.
- Go to the "/shop" page.
- Click on "Edit" to enter edit mode.
- Click on the "Customize" tab.
- Choose "Cards" for the "Style" option.
- Enable the "Product Description" toggle.
- Click on the "Theme" tab.
- Click on the 4th color of the theme colors and choose "black".
- Save the page to exit edit mode.
- Bug 1: The product description and the price in the product cards are
not visible.
- Bug 2: The scrollbar below the category buttons has the same color as
its background.
- Click on the "Mobile Preview" button in the backend navbar.
- Click on the "Filters" button on the page to show the offcanvas.
- Bug 3: The text color in the offcanvas is not visible and the
background color of the inputs is the "body" background color instead of
the "offcanvas" background color.
opw-3570774
closesodoo/odoo#153930
X-original-commit: add2b9273e90e3940ee52eee4ff42afa46c18a20
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: website_sale
Steps to reproduce the first bug (popover):
- Install the e-commerce on your website.
- Go to the "Customizable Desk" product page.
- Click on "Edit" to go in edit mode.
- Click on the "Theme" tab.
- Click on the 4th color of the theme colors and choose "black".
- Save the page to leave edit mode.
- Click on the "Add to cart" button.
- Hover over the cart in the navbar to make the popover appear.
- Bug: All the popover texts are not visible because they are white and
the background is white.
Steps to reproduce the second bug (extra price badge):
- Install the e-commerce on your website.
- Go to the "Customizable Desk" product page.
- Click on "Edit" to go in edit mode.
- Click on the "Theme" tab.
- Click on the 4th color of the theme colors and choose "black".
- Save the page to leave edit mode.
- Bug: The text of the "extra price" badge is not visible because both
text and background are white.
These two issues existed because the text color of those elements
depended on the body's background color. With this commit, the text
color for those elements is now determined by their respective
backgrounds.
This commit is a follow-up to this commit [1]. We also add the handling
of the text-muted color to ensure it remains visible if a modal has a
dark background while the body background color is light. Before this
commit, we only handled the opposite case (dark body and light modal).
This commit also fixes the text color of the button in a file input of a
form when the background color of the <body> is dark. Similar to the
other elements fixed in this commit, the text color of this button could
be invisible because it was the same color as its background.
[1]: https://github.com/odoo/odoo/commit/308b91c58b00300fd8dc52b9b4e2f7d1ab31f7b7
opw-3570774
X-original-commit: 0c2806576e85106d06f4275c9204e664f69793d8
Part-of: odoo/odoo#153930
Reproduction:
1. Install Sales, Email Marketing
2. Go to Email template by searching
3. Click the Sales: Send Quotation template and make a duplicate
4. Add empty lines in the template, till it almost reaches the end of
the page
5. Use slash command to add a Dynamic holder, and it’ll be positioned
below the page
Fix: compute the position by consider the height/width of the popover to
make sure it’ll be always in the page
opw-3373403
task-3442559
closesodoo/odoo#153969
X-original-commit: 583ef2441e6aa9a6d13f50991a0d1d3a54c31db1
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
In this commit
=============================================
Before if all the lines were of service the error was displayed in a banner
after error in response was received, but now before sending request the lines
are checked if at least one line is of product and error is raised.
closesodoo/odoo#153816
X-original-commit: 251ee180ba0342f6a8c84d0a3ee93156a1cb06e0
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Surabhi Varma (suva) <suva@odoo.com>
When invoicing public administrations, they expect the facturae
electronic invoice to contain the optional `<PaymentDetails>` node that
contains e.g. the bank account number to which they need to issue the
payment. We didn't provide these details.
This commit adds the necessary `<Installment>` nodes in the
`<PaymentDetails>` node for each installment in Odoo according to the
payment terms of the invoice.
Since we are fixing this in stable, we only add the payment details for
inbound payments and fix the `<PaymentMeans>` to `04` (Credit Transfer).
We also removed the stripping of whitespace for the signature, since it
turned out not necessary after introduced in [1]
[1] e5d69a73e2e781d00f67c0590a8fc13b09a06ebf
task-3734341
closesodoo/odoo#153931
X-original-commit: 7f88e41fb6b723c8d240344a50a5b4b8b4aa3f2f
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Steps to reproduce:
-Create a SO and sell a prepaid service in days
-Set the timesheeting to days/half-days
-Add a timesheet line on the task of the SO
-Go to database/my/timesheets and look for the timesheets
of the SO
-> The days ordered are wrong
Before PR:
If you confirm the SO with the timesheeted SOL's uom as
days and your timesheeting is made in days, the view will
convert the amount of days as if it were hours, showing wrong
values
After PR:
Made the report more robust, now converting whatever unit the
SOL has to either hours or days depending on the timesheet
setting
opw-3643988
closesodoo/odoo#153898
X-original-commit: 83ec944d6f8d534438fd223f44fd82b195aa3c06
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The string value of an empty array is `""` which is falsy. Prior to this commit,
if all optional columns headers were disabled in a list view, it would result in
a reset of those when the view is mounted the next time, instead of keeping them
disabled like in prior versions.
task-3692178
closesodoo/odoo#153831
X-original-commit: e600ed2fa2f2e612dfca20872356ae926dde0a54
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
Since fd2fb212c5, the
sepa provider (enterprise module) behaves as a custom
provider but despite some adaptations, the removal
of providers on module uninstall was not properly
adapted.
The uninstall of the sepa provider failed as its
inline template was not unlinked from the provider
before the template deletion.
This commit makes sure that custom providers are
correctly considered in the uninstall util supposed
to restore a provider to its state before the
installation of its module.
opw-3734697
opw-3721846
closesodoo/odoo#153843
X-original-commit: e70dbbae56472b124a59c38a1fbfeea23c8ec28b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
- Go to Website > Add menu items in a way that activates “auto-hide” (to
set the overflowing menu items in a “+” dropdown) if the viewport was
resized.
- Go to “edit” mode (adding the sidebar reduces the current window
width) > The “auto-hide” menu adaptation is disabled, and overflowing
menu items are still visible.
On [15.0 - 16.4]:
The original commit fixed the behavior described above by preventing the
unbreakable mechanism from detecting header changes and canceling the
auto-hide updates (see: [X-original-commit]).
In addition to the main fix, some other changes were also added to allow
correct editing of extra menu items [1]:
- The `_adapt()` debounce was replaced by a throttle that applies the
first menu adaptation immediately.
- We remember the state of the extra menu dropdown (open or not) if it
is there, which will be restored after the menu adaptation.
- When clicking inside an extra menu item, The extra menu is closed. We
prevent this default behaviour in "edit" mode.
Starting from 17.0:
The code from [2] fixed the same editor's rollback issue by using a
`withoutRollback()` to ensure that the `_adapt()` is called without
triggering any rollback.
This commit will only forward-port the adaptations from [1] since the
rollback issue was fixed using the new `withoutRollback()` tool.
[2]: https://github.com/odoo/odoo/commit/cbed990924887eb529056d89a042a92ba27b825b
Related to opw-3484742
closesodoo/odoo#153566
X-original-commit: 4713f95f18d7326b553464c0be6fdcd68b330292
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since commit [1], it is now possible to order the columns in mobile view
independently from the desktop view. When moving a column with an arrow,
if we are in mobile view, mobile order classes are added on the columns,
which only changes the order on mobile without affecting desktop. But if
we move on desktop view, then these classes are removed.
While it works well when using the arrows, this behavior is not the same
when moving the columns with the drag and drop. This means that drag and
dropping a column
- in the same snippet does not reset the mobile order classes;
- in another snippet does not reset the classes in it and does not fill
the gap left in the previous snippet if it was ordered.
This means that in the same snippet, there can be both columns with and
without the mobile order classes. This causes some issues:
1) Removing such snippets or their ordered columns causes a traceback.
Indeed, the `onRemove` code considers that all columns have the mobile
order classes if we remove one, which is why it fails when it is not the
case.
2) The arrows on the mobile overlay are not always correct and can also
be missing, because they depend on the order classes.
3) In mobile view, changing the order of the columns adds inconsistent
mobile classes on them, because of the columns that already have one.
This commit improves the drag and drop by also taking mobile ordered
elements into account, as it is the root cause of the mentioned issues:
- When a column is moved, the order classes of all the other columns in
the snippet where it was dropped are removed (so it behaves the same way
as with the arrows).
- When moving an ordered column in another snippet, the gap it left in
its previous snippet is now filled.
This commit also fixes the issues for already dropped blocks in existing
DBs, by
- adding a check when removing to avoid the first issue;
- removing the mobile classes at the start if they are inconsistent.
[1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba
opw-3697962
closesodoo/odoo#152487
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, an Outlook event without an organizer would fail to
sync with Odoo. This commit fixes this issue by allowing events without
an organizer to be synced from Outlook to Odoo.
opw-3701839
closesodoo/odoo#153683
X-original-commit: 4f441aa083413e475728f4f510afdbb9f15a26ef
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Issue:
- When a Helpdesk ticket is associated with a partner, this association
is not being correctly linked in the Timesheet module. As a result,
when attempting to group Timesheet entries by partner, the grouping is
inaccurate.
- The issue is caused by the '_compute_partner_id' not being triggered
due to the 'partner_id' being set in the '_timesheet_preprocess' method.
Steps To Reproduce:
- Go to Helpdesk
- Click on any project with the timesheet option enabled.
- Click on new
- Add title, customer and timesheet hours
- Go to Timesheet
- Group by 'partner'> the customer is not there
Solution:
- remove the lines where partner_id is set in '_timesheet_preprocess'.
opw-3667921
closesodoo/odoo#153740
X-original-commit: 811e84289952a0398f47aafb54f623664e8e191f
Related: odoo/enterprise#56446
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Kawtar Drissi El Bouzaidi (kdeb) <kdeb@odoo.com>
Steps to reproduce the bug:
- Add an "Image Gallery" on the website.
- Add a new image on the snippet.
-> Problem: the thumbnail of the first image of the carousel has been
replaced by the new added image.
To solve the problem, the triggering of the `image_changed` event has
been removed on extra image added. It was introduced by [1] to trigger
the re-rendering of the thumbnail when adding a new image on the
carousel but was actually useless. Indeed, the mechanism was the same as
now; when a new image was added on the carousel, the
`website.gallery.slideshow` that already handles the thumbnails was
re-rendered. An important thing to note is that the system was also
never intercepting this `image_changed` event as it was triggered on an
element that was not in the DOM (as it was removed at the
`_replaceContent()` call in the `slideshow()` method). However, since
[2], the images rendered by the `website.gallery.slideshow` are replaced
by the images (or the wrapped anchored images) returned by
`_getImgHolderEls`. Therefore, `$newImageToSelect` is part of the DOM
and the `image_changed` event is intercepted by the gallery option. As
the active carousel item is always the first one of the carousel after a
`website.gallery.slideshow` re-rendering, the system changed the
thumbnail of the first item with the new added image.
[1]: https://github.com/odoo/odoo/commit/85990768592cbdefbb178b5ffa38c1e29b9eeb87
[2]: https://github.com/odoo/odoo/commit/0fd2477d993e822fe6fd4497aace9f746af7a481
task-3736301
closesodoo/odoo#153717
X-original-commit: 3c4239212e7bedc3cb49f34d9eb0a23c3de0cbd6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
In commit[1] we changed the spacing of the activity button to dissociate
it from buttons that are "message/communication" oriented.
This spacing was unwanted so we need to revert it back.
task-3730089
[1]: odoo/odoo@e0491c1a62closesodoo/odoo#153100
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Description:
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in
case of `auto_join=True`), which is inefficient, as the `id` can be
retrieved directly from the current `model` table, instead of going
to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule`
of the `comodel` is applied, which is not the case when directly
referencing the `field` from the `model`. So in some cases using an
explicit `.id` would be a wanted, if the intention was to apply the
`ir.rule`.
Fix:
Remove the `.id` from left leafs of domains that if the field is
stored, and the `comodel` doesn't have `ir.rule` associated with it,
or the `ir.rule` application is redundant/not needed.
task-3735923
closesodoo/odoo#153460
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Versions
--------
- 17.0
- 17.1
- master
Steps
-----
1. Go to Settings / Manage Languages;
2. select your current language;
3. set First Day of Week to something other than Sunday;
4. go to Time Off app.
Issue
-----
Weeks in year overview still start on a Sunday.
Cause
-----
Commit 52dae7a2f0 hardcoded `firstDay` to
Sunday for the `hr_holidays` module. This was a workaround to some
issues with `fullcalendar`'s week number calculations.
Solution
--------
Remove the hardcoded `firstDay`, and add a custom week numbering
function to be used on week, month, and year calendar views for
consistent numbering that allows for different first days of the week.
The function returns the ISO week number of the Monday nearest to the
configured first day of the week, i.e. the following Monday when first
day is set to Friday, Saturday or Sunday, the previous Monday if first
day is set to Tuesday, Wednesday or Thursday.
There were 3 main considerations for deciding a week numbering method:
1. no exisiting setting for users to decide on a method;
2. the ability to pick a first day of the week independent of locale;
3. the version of `luxon` used being unable to factor in locale.
Addendum
--------
This commit doesn't fix the issue with group-by week numbering in list
view. These stem from `babel`'s inconsistent locale defaults and
inability to take user-configured first day of the week into account.
opw-3668175
closesodoo/odoo#148623
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
The goal of this commit is to improve the comment in the `loadImageInfo`
method.
We decided to retarget [1] to master for a potential merge over there,
although it might just get cancelled entirely. We leave the small
regression in stable: not being possible to customize an image (filter,
optimization, etc) of an image-added-by-url when the URL is actually...
an image in a static folder of your own instance's website. This worked
in the past but this is kinda a weird use case which has alternatives.
Fixing it in stable would be choosing between two possibilities:
- Checking that the URL is actually a "local" URL -> this is exactly
what we cannot do anymore if we want another bug fix to remain: the
updated comment explains why.
- Also supporting customizing images added by URL for "external" URL
-> this is too risky in stable, that is why [1] will be considered in
master only, although it will not be strictly necessary over there
since the improvements made with [2].
[1]: https://github.com/odoo/odoo/pull/151858
[2]: https://github.com/odoo/odoo/commit/943944dd249c15de870d6800d89e48d54a422e5aclosesodoo/odoo#153716
X-original-commit: 9d827cc22245a6706d5b6b94ac3c30a3d8cb238b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Add method '_get_discount_product' to allow to override the product used
by the sale_order_discount wizard.
closesodoo/odoo#153652
Signed-off-by: Jérémy Kersten <jke@odoo.com>
When a user is modified to grant access to new groups, user is
auto-enrolled to all slide courses that have a auto-enroll policy for
any of the new groups.
However, that auto-enrolling process was not working correctly due to
how values to be written to the user are coming. In order to know what
are the actual new groups, values need to be pre-processed, which was
not being done.
This commit fixes the above issue by pre-processing written values
before extracting new groups.
closesodoo/odoo#153634
X-original-commit: e27be4a81c304c2d749b4417d2184cfed07eddf3
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Rules always have a pricelist, so we can avoid an
useless database query when we are computing the
prices without any pricelist.
Also makes sure that the modified context used
for the pricelist items search is not propagated
by enforcing the same context in the returned
rules.
closesodoo/odoo#153624
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, to render the table, the project task list
view computed the list of selected records once for each cell,
and then iterated over that selection to check whether selected
tasks were all associated with the same project (to set the
stage_id field readonly if not). However, computing the selection
requires to iterate over all records, so the rendering was O(n^2).
As a consequence, the rendering of (not so) large tables was very
slow (~1s for 80 records).
With this commit, we compute only once for the whole table whether
the selection contains records from different projects.
closesodoo/odoo#153611
Signed-off-by: Géry Debongnie <ged@odoo.com>
How to reproduce the error:
1. Go to Contacts.
2. Select a Contact of Type Company:
Find and select a contact that is a company type and to which a
price list has already been set up previously.
In case no price list has been set previously, set the price list
and save the contact.
3. Edit the contact and modify the address state without the need to
save the changes.
4. View the PriceList:
After changing the province, look at the price list field. You can
verify that the price list has become blank immediately after making
the change in state, without the need to save the changes.
Current behaviour: the price list is deleted when the state of the address is changed.
Expected behaviour: keep the previously set price list.
Explanation:
The code was incorrectly using "p.id" instead of "p._origin.id" to get
the contact ID. This resulted in a non-existent key being retrieved and
caused the loss of the price list in the contact when changing the province.
The fix adjusts the code to correctly use "p._origin.id", ensuring correct
retrieval of the ID and avoiding unwanted changes to the price list.
Example of data obtained by debugging:
- Edited user: Deco Addict
- Data obtained in "res": res {53: product.pricelist(1,)}
- Data retrieved in "p.id": (p.id) > NewId_53
- Data retrieved at "p._origin.id": (p._origin.id) > 53
TT47536
closesodoo/odoo#153326
X-original-commit: 570715ecc6c9b105a2edaed23a68f557e5cf1987
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
While fixing a non deterministic test failing
on nightly l10n builds, slight incoherences between
sale & website_sale tax computation have been noticed
in the computation of the contextual price (used in
some snippets).
This commit fixes the test, making sure it doesn't fail on
l10n builds, but also uses the same tax util in website_sale
than in sale, to make sure the displayed amounts are coherent
(and supposedly correct).
runbot error: 52831 (& a bunch of others)
closesodoo/odoo#153299
X-original-commit: 91f9057c73810c34a4b0b85a60c84bb1c482efa4
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Specification:
This commit target the scenario when image is in selection and the toolbar
displays AI option for it, which made no sense as the generated response
will replace the image.
After this commit:
The toolbar has been updated to show AI option only for text based scenario
task-3733320
closesodoo/odoo#153190
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Current behavior:
When printing the bill before the order has been paid, the QRCode to get
the invoice shouldn't be shown.
Steps to reproduce:
- Activate the option "Show QR Code" in the POS settings
- Create a new order
- Add some products
- Click on "Bill" button
- The QRCode is shown
opw-3703720
closesodoo/odoo#152918
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
How to reproduce:
- Install crm with demo data
- Open the crm app
- From the menu "Configuration -> Activity Plans", create a plan
- Open a lead
- Schedule the plan just created for the lead
The log message in the chatter display due date in the wrong format:
Year(4)-month(2)-day(2) instead of the user date format (if your date format is
that one, please change it for testing).
This fixes the problem by displaying the date in the user format.
Task-3639909
closesodoo/odoo#152217
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit's purpose is to fix the re apparition of personnal stage on
the todo app when personnal stages are deleted one after the other.
Step to reproduce:
-login as Marc demo
-open todo
-delete any personnal stage without any todo in it
-delete any personnal stage with at least one todo in it
The personnal stage deleted first is now present again in the kanban
view. Note that it is only a frontend bug. The record has been correctly
removed from the db, and any action with it will trigger a cache miss
exception and reloading the view completly will removed those ghost
stages definitly.
Source of the problem:
The problem is that the deletion is only reloading the view completly
when a record with child data is removed. More precisly, the
_deleteGroup function of the dynamic list triggers an rpc call to update
the config of the component only when a record with child data is
deleted, and that data need to be switched to another record, while when
it is an empty record, the record is simply removed from the group
field of the list. The issue is that there is thus a mismatch between
the group in the list.config.groups and the list.group. And when the
config is updated, only the list.config.groups is used to update the
config, meaning it potentially still contains element that were already
deleted.
Solution:
Doing a check up on the list.group to ensure that any deleted element is
also removed from the config when an update is triggered.
Note: I dont why Mitchel admin did not trigger the bug. Code wise, it
should happends no matter the access right of the connectedd user.
Version affected:
17.0+
task - 3553101
https://www.odoo.com/web#id=3553101&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=formclosesodoo/odoo#142536
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit fixes an unconsistent forestack icon within the `sale_stock`
module.
Prior to this commit, the forecast icon was using a `text-primary` class,
making it unconsistent regarding the other forecast icons.
We also add a missing `cursor-pointer` class to fix the improve the hover
state and the visual feedback of the link.
task-3582145
closesodoo/odoo#153618
X-original-commit: e3c7273dbd8c9945bd5b983e864bbb0530114df4
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
In tax report, ve38 line should display the tax
excluded amount, not the tax amount.
opw-3609402
closesodoo/odoo#153558
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
In case of tax update, tags were remaining even if user
deleted them.
This is because we don't clear the repartition lines before
reassign them in `_pre_reload_data()`
Part-of: odoo/odoo#153558
Steps to reproduce:
- Create a child company.
- In the child company, create a new sales journal.
- Create and confirm an invoice using this new journal.
- Attempt to create a credit note from that invoice.
In this scenario, you would encounter an error.
Cause:
The `AccountMoveReversal` wizard is currently setting its company to the
root company of the moves, which in this case is the parent company.
However, its journal is set to the one created in the child company.
This mismatch causes an error due to company inconsistency.
Fix:
The `company_id` of `AccountMoveReversal` will now be assigned to the
company of the moves, rather than the root company. To ensure this works
correctly, we also added a check to guarantee that all moves being
reversed are from the same company.
Note:
This fix also resolves an issue where a traceback occurred if two
invoices were created (one in the child company and another in the
parent company) and an attempt was made to reverse both simultaneously.
opw-3640719
closesodoo/odoo#153396
X-original-commit: cd62e3fcaab3e71e606607308cace739bc480c4f
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
**Current behavior:**
Trying to create an opportunity as a portal user and leaving
any of the fields empty will cause an unnecessary exception
dialog to flash on screen.
**Expected behavior:**
Submitting the form with empty required fields will just prompt
the user to add values to all fields.
**Steps to reproduce:**
1. In the Contacts application, go to a portal user and in the
Partner Assignment notebook tab, give them a partner level
2. In the CRM app, create a new lead and assign the portal user
who was granted the partner level as the customer
3. Login as the portal user, and convert the lead in My Leads
to an opportunity
4. Go to the my/opportunities website menu
3. Select 'Create Opportunity' in the top right and leave
any/all of the fields empty then select 'Confirm'
**Cause of the issue:**
The catch block in the _buttonExec() function is rejecting its
Promise when it catches anything aside from an RPCError.
**Fix:**
Only reject the Promise when the catch block encounters an
actual Error, preventing dialog window popups when non-critical
exceptions (non-Errors) are thrown.
opw-3703238
closesodoo/odoo#151982
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Product template "property_account_expense_id" and "property_account_creditor_price_difference" fields must stay editable in cases even if not "can be puchased".
Since it being readonly is trivial, better leave it writeable instead of implementing cross module readonly logic.
closesodoo/odoo#150601
Task: 3695677
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Issue:
When the notification webhook is enabled for Adyen, sometimes the response back causes an SQL concurrent update. Odoo then creates a retry towards Adyen, charging the customer card several times. Both the notification webhook and the payment controller are hit, and try updatingthe same row simultaneously, which causes this behavior.
Steps to reproduce:
This bug is not reproducible due to a connection issue for the Adyen test account. However, if the payment request would implement idempotency we could prevent billing the customer on the same request if the request reaches this collision and is retried multiple times.
Description
A first payment request is sent to Adyen. The card is charged and Adyen answers that all went as expected.
We try to process the payment, but a concurrent access error occurs.
A retry is done.
A payment request is sent again to Adyen, The card is charged AGAIN and Adyen answers that all went as expected.
We try to process the payment, but a concurrent access error occurs.
For each retry, the request is sent and the card is charged.
If the first retry succeeds, then Odoo can finish the process. There will be only 1 payment transaction on Odoo's side
(others have been rollbacked) but there will be 3 on Adyen's side and the card will be charged 3 times.
This PR fixes this behaviour by adding the idempotency key to the headers with the hash of the transaction
reference and the database UUID, we prevent duplicate payments to happen.
OPW-3584300
closesodoo/odoo#153734
X-original-commit: cf035accd8fd633de84c86e2bf426c900c865b9f
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Mehdi Rachico (mera) <mera@odoo.com>
In b69917e[1] the cron implementation was changed to unlink old visitors in
batches of 1000 records. This was meant to deal with memory/timeout
errors when dealing with large amounts of records.
However it still searches for records with no limit, which in high
record count scenarios and based on instance resources may still
generate memory/timeout errors.
Technically it could be considered "fine" for the cron to timeout since
every batch is committed, so previously unlinked records are not rolled
back and the cron should eventually delete them all.
However there are some edge cases where memory/time out errors would not
be fine, like the cron failing during the first batch, which means no
unlink operations would be committed to the database.
Errors that are "fine" also generate noise and leave administrators
wondering which errors they should ignore and which they should not. It
also alarms non-technical customers since after all, they are seeing
a reported error.
Therefore the search limit and batch size have been added as arguments
to the cron. This is completely opt-in since they have the previous
values as their defaults. This makes it easy to customize and tune the
performance of the job accordingly if required.
[1] https://github.com/odoo/odoo/commit/b69917ec0e508f8354d831525c5c48ee79b5967a
X-original-commit: e8a4b1f6a239753f66aa827e8e0d67ca4270dba3
Part-of: odoo/odoo#153707
The onExternalClick custom hook keeps a reference to elements that may
no longer be in the DOM, this can cause entire sections of the DOM that
are no longer needed to be kept in memory, and can also retain the
associated Owl components and their data.
To solve this, we set the downTarget and upTarget to null after calling
the callback. In practice they are no longer used in the code but we are
keeping it for stable compatibility.
closesodoo/odoo#153654
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, when exporting its state so that it could be restored later,
the relational model would export its config. The problem is that
because this config is a reactive object, it keeps a reference to the
components that may need to be notified by that reactive object. This
exported config was then stored on the next controller, which would be
retained by the next config, etc.
This commit fixes that by exporting a raw version of the config.
Part-of: odoo/odoo#153654
Sébastien Delafond