Steps to reproduce:
- Install accounting
- Create more than 6 analytical tags
- Create an invoice
- Create a payment
- Go in Accounting>Actions>Reconciliation, tab Manal Operations
- In the field Analytical Tag, click on 'Search More' and selected 1 or multiple tags
Issue:
Void tags are displayed
Solution:
Fetch the field `display_name`
ref commit: 84f0644802865c6454014059842eb6a9d4fd40e4
opw-2734029
closesodoo/odoo#87311
X-original-commit: 936bad32cf1024570da4880ccc5375b02b30c1c2
Related: odoo/enterprise#25631
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Current behavior :
Incoterm isn't printed on quotation/order report with DIN5008 layout
Steps :
- Install Sales, Inventory and Germany - Sale
- In Settings :
- Enable Incoterms under Sales section
- Select DIN5008 Layout (external_layout_din5008) for documents
- Go to Sales and get a new one
- Select an incoterm in Other info tab
OPW-2759568
closesodoo/odoo#87184
X-original-commit: b6db1b7ba3439d2b0ae7ef7ccc7ee15e1642ecba
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
Technical note: We didn't change ".app_settings_block h3" because it is used
all over the place. Instead, we've overridden the margin and padding using
bootstrap classes on that specific element.
Task-2792977
closesodoo/odoo#86456
Related: odoo/enterprise#25289
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
mass_mailing has an override of _getCSSColorValue which was basically
never used since the option it's linked to was mostly inactive. Now it's
active it became obvious there is a mistake in it that causes a
traceback to occur when no color is passed to it. This adds the same
check as in the original method and thereby prevents the traceback.
task-2760157
closesodoo/odoo#84926
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The shape feature only applies to attachments. This moves images from
mass_mailing snippets into attachments so they can be shaped in the
editor.
task-2760157
Part-of: odoo/odoo#84926
Email clients do not support svg images so we can't support animated
shapes in mass_mailing. This removes them from the options.
task-2760157
Part-of: odoo/odoo#84926
This allows users to use the shape feature on images in mass_mailing.
Since email clients do not support the svg file type, it converts these
svg images into png images on save.
task-2760157
Part-of: odoo/odoo#84926
Prior to this commit, when a user edits the Shop page, clicks on the
pricelist dropdown and finally clicks elsewhere, a traceback occurs:
`Uncaught TypeError: Cannot read properties of undefined (reading
'getColorNames')`
This commit ensures the link tools is not toggles on dropdown links,
i.e. the customizable links selector does not contain the dropdown
anymore.
task-2695091
closesodoo/odoo#87300
X-original-commit: 73b98a53e8bd19b3b96502d6006b002819287e44
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Thibault Libioulle (tle) <tle@odoo.com>
This fixes erroneous matching of product when the product code in an invoice is ambiguous and fixes a missuse of the label from a product rather than the one on the invoice
Previously, a product would be set on an invoice line even if several products share the product code and when a product is set the label is the one of the matched product
Now, a product is set if the code matches one and only one product and the label used is always the one from the invoice
closesodoo/odoo#87313
Task: 2764978
X-original-commit: 47d5dff9f9a8eb0b4eebdf56e2a2d46618972453
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Florian Gilbert <flg@odoo.com>
Duplicate sending should be considered as positive outcome.
We also post a message on the invoice to make the user aware.
closesodoo/odoo#87292
X-original-commit: b49210bdf507850306d6f19306ea8cd6a91e3316
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps :
Install Sales, Project and Inventory.
Create a Storable Product.
Create a SO with this product, but do not confirm it.
Change this product :
> Type : Service
> Sales > Service Tracking : Create a task in SO's project
Confirm the SO.
Issue :
Neither a delivery or a task is created.
Cause :
Confirming the SO calls SO._timesheet_service_generation(),
which filtered its SOLs based on is_service to 'create on order'.
As this field is not updated when changing the type of the product,
the SOL with the service is filtered out.
Fix :
Update SOL_.is_service when changing SOL.product_id.type.
opw-2786655
closesodoo/odoo#87308
X-original-commit: f1518e8c9a6c7819a0d7f72a524c189cd9de5fc6
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
The previous code generation for coupon used `getrandbits` which
provides a less randomised code than uuid4 causing undeterministic
errors during the tests.
TaskId-2786904
closesodoo/odoo#87299
X-original-commit: 7c2d68b466e13a25a6dd7091383b1f9810f1a630
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Current behavior:
If you activate the packaging options of the inventory
tab. The external link of the packaging type in the inventory tab of a
product is invisible.
Steps to reproduce:
- Have inventory module installed
- Activate the packages & product's packaging options
- Go on a product page and then go in the inventory tab
- Add a line in the packaging tree view
- There should be an exteral link next to the packaging type after you
selected one
- The external link is invisible
Note: similar issue was also present in the Document's workflow rules.
opw-2749832
closesodoo/odoo#87305
X-original-commit: 57a92e6a1178e3bd9d9f8995388cdc67a354c585
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Before this commit:
There is an unused method _channel_get_livechat_partner_name
After this commit:
Removed unused method
Task-2801010
closesodoo/odoo#87158
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: web, website_slides.
Specifying both side of a relation when seeding test data is cumbersome.
Let startServer method handle it.
task-2792108
closesodoo/odoo#86939
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This fixes a problem that occurs with conditions on one2many fields,
where most conditions are translated with a subquery like
"model".id IN (
SELECT "comodel"."model_id" FROM "comodel" WHERE ...
)
The issue occurs when the subquery return NULL values, i.e., when the
field "model_id" in the subquery above can be NULL. The fix simply
consists in adding the condition "model_id IS NOT NULL" in the WHERE
clause of the subquery.
The problem with NULL values returned by subqueries is the fact that
they make the SQL condition undetermined instead of false, and this
discards some of the results returned by a query. Simply consider:
id NOT IN (1, 2, 3)
The value id=3 makes the condition false, while i=4 makes it true. Now
consider that the set also includes a NULL value, like:
id NOT IN (1, 2, 3, NULL)
The value id=3 makes the condition false, but the value id=4 makes it
undetermined. Therefore this condition is actually undetermined for all
possible values of id, and a query containing that condition simply
returns nothing!
closesodoo/odoo#87285
X-original-commit: 6d680bac0333c6c7ce9f056cba0e1f7e9fa22f9c
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
This fixes two problems that occur with conditions on many2many fields:
the subtle bug caused by NULL values that are returned by subqueries,
and the performance of those subqueries.
The problem with NULL values returned by subqueries is the fact that
they make the SQL condition undetermined instead of false, and this
discards some of the results returned by a query. Simply consider:
id NOT IN (1, 2, 3)
The value id=3 makes the condition false, while i=4 makes it true. Now
consider that the set also includes a NULL value, like:
id NOT IN (1, 2, 3, NULL)
The value id=3 makes the condition false, but the value id=4 makes it
undetermined. Therefore this condition is actually undetermined for all
possible values of id, and a query containing that condition simply
returns nothing!
Regarding performance, consider a domain like [('tag_ids', '=', False)].
It is currently translated in SQL as
"model".id NOT IN (
SELECT "model_id"
FROM "model_tag_rel"
WHERE "model_id" IS NOT NULL
)
PostgreSQL does not handle well this "NOT IN" expression when the
relation table is large, and uses some very inefficient query plan in
that case. The inefficient query plan is possibly related to the
special handling of NULL values, by the way. This commit changes the
above expression to a "NOT EXISTS" expression (as below), which is
executed with a much more efficient query plan, even with large tables.
NOT EXISTS (
SELECT 1
FROM "model_tag_rel"
WHERE "model_tag_rel"."model_id" = "model".id
)
This change was motivated by a use-case with 2.7M account moves, 11M
account move lines and a many2many relation table with 2.3M lines
(`account_move_line_account_tax_rel`). The query was timing out (15
minutes), and it now takes 15 seconds.
We have replaced all the conditions on many2many fields to use the
relational operators EXISTS and NOT EXISTS.
A test has been added to reflect a case where the many2many table
contains NULL values, like the one for channel_partner in regards to
partner_id and guest_id.
task-2753782
X-original-commit: 334b2aa2aa437d2ed86130f2ed426025f8fe4b86
Part-of: odoo/odoo#87285
Co-authored-by: Didier Debondt <did@odoo.com>
By adding an index the cost of the SQL's will be a lot lower.
See #86615 for info/sample
closesodoo/odoo#87287
X-original-commit: 44b445eba6287348211e002235e1d003b45f2d6e
Signed-off-by: William André (wan) <wan@odoo.com>
No longer show the reserved column from by-products production registration on an MO.
Task ID: 2797692
closesodoo/odoo#87225
Pr: https://github.com/odoo/odoo/pull/86768
X-original-commit: 7aa08fe325490bf6ca5efe8b9b7be4bcae843826
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, if an option targeting an element had a
data-no-check attribute this had the effect that all other options
targeting this element were also displayed even if they did not have a
no-check attribute (no-check => display the option even if it is
a non-editable element).
The issue came from the is() function of _computeSelectorFunctions which
did not take into account the no-check as it should.
Note: this is fixed in stable only as custom apps may rely on the broken
behavior. An issue with this in stable can be met by *hiding* the
related unwanted options with `_computeVisibility`. No case of this
problem currently exists in the Odoo codebase (but it will, that's how
the bug was found).
task-2710582
closesodoo/odoo#86011
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Description of the issue/feature this PR addresses:
The purchase order document in the German localization
(l10n_din5008_purchase) is titled "Purchase Order" way too early. This can
lead to confusion. In the worst case, the vendor will treat the request
for quotation as purchase order.
Current behavior before PR:
If the document has been sent once and then is sent again (either to the
same recipient, or another), the document is titled "Purchase Order",
which will most definitely be treated as such by the recipient.
Desired behavior after PR is merged:
As long as the document is not confirmed (states "draft", "sent", "to
approve"), the title has to be "Request for Quotation". After that
(states "purchase", "done"), the title has to be "Purchase Order".
closesodoo/odoo#87276
X-original-commit: 1238b3f7441f89d959638b9b4520ebfa19430dc5
Signed-off-by: William André (wan) <wan@odoo.com>
After installing l10n_be_hr_payroll, the address, email, phone and bank account number take half of the dedicated space.
This commit makes the fields take the dedicated space
task-2790206
closesodoo/odoo#86098
Related: odoo/enterprise#25126
Signed-off-by: Kevin Baptiste <kba@odoo.com>
methods for others to extend functionality
1. _prepare_resource_leave_vals_list() that will prepare value for
creation
later in _create_resource_leave()
2. _create_resource_leave() now calls the
_prepare_resource_leave_vals_list()
instead of having done the job itself
closesodoo/odoo#87081
X-original-commit: 6040670f24da60b1f1b2f1814423c473cc060c8c
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
- Add a BOM
- Try to add the product P1 as a component > save > validation error is triggered
> it's not possible to add the same component as the product to produce > correct behavior
- Create a manufacturing order:
- Select the product “P1” as product to produce
- Add the product “P1” as component
- save
Problem:
no validation error is triggered, It's possible to create a MO in which the final product is included in the component > wrong behavior
opw-2796750
closesodoo/odoo#87262
X-original-commit: f38727ee4e7b6596a9da5f3285c7622da0ac6772
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Reproduction:
1. Create a survey or use an existing one
2. Share it via mail
3. Try to open a link provided in the mail
Reason: the conditions for public users in _check_validity() are not
refined enough. The link in the email has answer_token, while the
general Survey URL is a direct link to the survey. However, the
condition ”request.env.user._is_public() ” is true for both cases. This
leads to redirection to the homepage for survey links in the email.
Tested locally that sending two different recipients same survey by
email will assign two different answer tokens
Fix: add the answer_token to the condition. If there is an answer_token
part, it means this link is specific for a partner, and no user check is
needed. Because ideally, only this partner received the link. If there’s
a leakage, it’s probably his/her problem
Original commit: 3c71f66bb541fcf31f31e75b60f7825d26109bc4
First fix: cffc732e58c14541abcf06bb0d58add224396b7c
opw-2795134
closesodoo/odoo#87258
X-original-commit: 5599995d80d1cefaa7ddcb91a201756acc8cbf02
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When the admin user logs in for the first time, their timezone can be updated based on the cookies of their browser.
In such case, the timezone of the default working calendar should be updated too.
Related: https://github.com/odoo/odoo/pull/83262/
Task 2759592
closesodoo/odoo#87061
X-original-commit: 3c56be1732d219ed69efe5f18bd7931959b7c333
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Show the optional field analytic_tag_ids with widget many2many_tags in
view account.move.line.tree.grouped
opw:2778260
closesodoo/odoo#86990
X-original-commit: fa4d41bcebde71c5aa7bbf53dd19bdaab748f4c8
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Simon Goffin <sig@odoo.com>
This commit updates the cart quantity even if the html page comes from
browser cache, i.e. the user comes back to a previous page with the
browser back method.
task-2741846
closesodoo/odoo#84861
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The implementation seemed buggy as you had to click twice on a rating to
activate the filter; this fixes the problem.
It also improves a bit the interface:
- by allowing to click on another rating directly without having to deactivate
first the current filter
- by replacing "Remove Selection" by a red fa-times
- by adding a spinner on the messages zone while the messages are loading when
the connection is slow (the spinner appears only after half a second if the
server doesn't response in the meantime)
- by setting some minimal heights to avoid seeing the footer moving when
switching from course to review and when changing the star filter (which change
the number of message displayed)
Technical notes:
The double click problem was caused by an update of the view when the rating
filter is changed. When re-clicking on the same rating the view was not
re-rendered and the change (selection) in the view were kept.
To solve that problem we have implemented the selection directly in the view
and the css. As it doesn't rely anymore on changes performed in javascript
in the dom, the re-render of the view after fetching the data from the server
reflect the selection done by the user.
Task-2754954
closesodoo/odoo#85757
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
To reproduce
============
- Connect with Mitchell Admin
- Go to Employee -> Settings and uncheck "Skills Management"
- Go to Settings -> Users, create a user "Test" and give him access to 2 companies (e.g. My Company [San Fransisco] and My Company [Chicago])
- Set current company to My Company [San Fransisco], go to Employees, create an employee record and associate it with your test user (in HR Settings tab)
- Set current company to My Company [Chicago] and create another employee and associate it with your test user too
- Connect as "test" user and go to my profile
- Try to change your langage (From English US to French) ==> Access rights error
Purpose
=======
When the `OnChange` is triggred we try to read the two employees linked to this user, but one of this employees is in unslected company
which leads to Access rights error.
Specification
=============
To solve the issue the domain in the security rule **Employee multi company rule** has been updated, where we added the condition
`('user_id', '=', user.id)` which gives the user the ability to read the needed data.
opw-2793123
closesodoo/odoo#87244
X-original-commit: 5916e15f6fa29fd89e12472b316475e757001945
Signed-off-by: Kevin Baptiste <kba@odoo.com>
We have a bug when we were computing the invoice rate that is used to
report to AFIP. The rate we were setting was an old rate that references
the day that the invoice was created and not the rate of the day where
the invoice was validated. This was happening because the
l10n_ar_currency_rate field that stores this value was computed before
posting the invoice. At that time the date field store the value of the
date where the invoice was created and had not been updated yet with the
accounting date.
Moving the l10n_ar_currency_rate field calculation after the invoice
post solves the problem and now the l10n_ar_currency_rate has the rate
of the accounting date.
Part-of: odoo/odoo#84470
Original commit: aac1165655d31ba3bca4b105e0c905534e91df93
closesodoo/odoo#87163
X-original-commit: ac57ac559d973a1c4c2050fa514668d20bd610f0
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce the bug:
- Go to Inventory > Transfers > Select a ready transfer with no qty done
- Print > barcodes (ZPL) or barcodes (PDF)
Problem:
The file is empty because there is no qty_done.
Solution:
If no qty is done, then print all barcodes as if picking is done.
It makes sense, for example, when a user wants to print the barcodes before the product is delivered
but if at least one move_line has a Qty_done then do not print the other move_lines which have a qty_done of 0
opw-2780365
closesodoo/odoo#87151
X-original-commit: 3229d73dd11ddb02415d61c47f41e857742887b7
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to follow
- Go to the product page
- Open studio
- Click on the picture and set the size to large
- Save and quit studio
-> The size doesn't change
Cause of the issue
Studio sets the size attribute on the field as `[0, 270]`
This means the picture should have a height of 270px and an unspecified width.
But for that to work, we need to handle the case were only one
dimension is set.
opw-2745625
closesodoo/odoo#87226
X-original-commit: 50368a9db8ac67986cf64ff84ee625cbf7a90a1f
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Incorporate Andrea Arce (andreaarce) as Vauxoo's contributor
I confirm I have signed the CLA and read the PR guidelines at
www.odoo.com/submit-pr
closesodoo/odoo#87218
X-original-commit: 89a086c8fe06a4823f405e4f14a77396b520fe88
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
There is a concurrency issue in the action service:
1) be in an action with several views
2) execute another action (e.g. by clicking on a menu)
-> [calls the route "/web/action/load", and it takes a while]
3) meanwhile, click on another view in the view switcher
If the call to "/web/action/load" is long enough, it may happen
that the view requested in step 3 is briefly shown before the
action associated with the menu clicked in step 2.
In this scenario, the action of step 2 should never be displayed,
because the user requested something else afterwards (in this
case a switch view).
One can produce a similar issue when restoring a previous action
of the breadcrumbs instead of switching view.
This commit fixes those two issues by registering a resolved
promise in the keepLast (concurrency utils), s.t. it "cancels"
the potential current operation (in this case, the call to
"/web/load/action").
closesodoo/odoo#87204
X-original-commit: fb9c8cd6fee476d2506b8c1338bf88c4520ea7b6
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit
When trying to open the linktool on link that are not
`isContentEditable`, the linktool was initialized and not
showed in the sidebar.
After this commit
As it does not make sense to edit a link that is not editable,
prevent the linktool from being initialized in the first place.
task-2802592
closesodoo/odoo#87203
X-original-commit: 4a634f2c5bfceb3f2dc200f9b391ef1cdbc0e697
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This prevents a traceback when no closest block to the root node can be
found in the sanitizer.
task-2796371
closesodoo/odoo#87187
X-original-commit: 2104f33985472cd59f067d2f1403518a332fac6d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Until now using a groupby on a view containing a reified field added
with studio was not possible.
Because `read_group` uses these pseudofields as simple fields when they
are not actually columns in the table.
With `read`, `write`, `create` and `fields_get` it was already
supported.
This commit solves this problem by ignoring reified fields in an
override of `read_group`
opw-2793148
closesodoo/odoo#87186
X-original-commit: a25e25aeab3ed6aa1af57fac13312346b723dbf8
Signed-off-by: Raphael Collet <rco@odoo.com>
Yolann Sabaux