Steps to reproduce:
- Drop an Text - Image block
- Click on the Image
- Click on the link button next to replace
- Try typing a URL
=> Typing a URL is hard because the widget keeps re-rendering
Reason: Since [1], the jQueryUI urlcomplete widget was changed into an
OWL widget. This added a call to `urlChosen` on input, which leads to
the SnippetsMenu re-rendering the options.
This commit fixes that by remove the call to `urlChosen`. Nothing is
lost since the input is already handling its own changes. Instead,
urlChosen is only called when selecting an element from the dropdown.
[1]: https://github.com/odoo/odoo/commit/86a9171ec7790aa09f2b9a50dcb26deb029e8bedclosesodoo/odoo#161045
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Co-authored-by: =?UTF-8?q?Nguy=E1=BB=85n=20=C4=90=E1=BA=A1i=20D=C6=B0=C6=A1ng?= <daiduongnguyen2709@gmail.com>
In `SET_FILTER_MATCHING_CONDITION` we would call `SEE_RECORDS_PIVOT_VISIBLE`
twice but since the function returns a boolean value, the second call
was useless as we already knew the outcome. This revision alleviates a
bit the cost of computing the cells' clickable actions.
On A sheet with 480 visible cells, each of them matching the full
condition, the time spent in `getClickableCells` goes from 19ms to 14
ms on Google Chrome and from 42ms to 29 ms on Firefox.
closesodoo/odoo#161656
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Issue: When a course is set to 'On Payment' and
linked to our 'Course Access' product, users
encounter an issue where they cannot view the
final screen of the payment process when selecting
payment methods like 'wire transfer'. This occurs
because the payment status remains 'pending', and
the user has not yet been granted access to the
course, meaning no invitation link is available.
Steps to Reproduce:
1. Install website_sale_slides.
2. Create or modify a course with the 'On Payment'
status.
3. Link it to a 'Course Access' product.
4. Navigate to the website and attempt to purchase
the course.
5. Proceed through all the steps of the payment
process.
Solution: The template needs to accommodate
scenarios where certain payment methods do not
immediately provide an invitation link.
Even without the invitation link, it should still
display the last payment screen, awaiting payment
confirmation to grant access.
opw-3683024
closesodoo/odoo#161618
X-original-commit: eee6222763b4d88f75994b498d15cd4358899fc1
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
Create company A with company currency USD, company B with company
currency VND.
Set company B-VND in payment terms
closesodoo/odoo#161044
Expect: currency payment terms is VND
Signed-off-by: William André (wan) <wan@odoo.com>
Issue: In Link Tracker for our website, when generating the link, if we
try to copy the generated url with the copy value, instead of copying
the url we are getting undefined.
Steps to reproduce:
1. Install website_links.
2. Go to the website and go to Site > Link tracker.
3. Generate a new link and try to copy.
Solution: Due to the recent changes that came from the changes made in
9638423 where we replace the ClipboardJS with Web API and hombrew
polyfill, there are still some button that is not adapted yet, and in
this case what happens is that we have a difference dataset format for
the clipboard content, being 'clipboardText' instead of 'clipboard-text'
opw-3806495
closesodoo/odoo#159674
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When updating the categories, if by any chance there is a loop in the
category hierarchy, the current code was falling into an infinite loop.
With this commit, the graph loop is broken by clearing a parent_id, and
if the resulting module category path is wrong, a clean new one will be
recreated anyway.
This allows unblocking uncomfortable situations where people cannot
update the modules list any more. In 15.0, [a check][1] has been
introduced to prevent the existence of recursive categories, but as it
is a python check it doesn't prevent corrupted data to remain corrupted.
OPW-3704007
Related to odoo/upgrade#5574
[1]: odoo/odoo@6932714200closesodoo/odoo#161583
X-original-commit: f2765d2cab5671a010404c36842bf1b4c4d6350b
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Since [1] positioning of popovers targeting an element contained in an
iframe is permitted.
This commit will ensure the popper's element positioning is correct in
the following case: have a popper
- outside an iframe
- targeting an element that is inside it
- and no container element has been given (default is used)
**Before this commit**
The default container that is used is the target's owner document
element, a.k.a. the iframe's html element.
**After this commit**
The default container that is used is now the popper's owner document.
** Side notes **
This bug has been found when working for the following taskid-3603843
It is required for this task and will get fw-ported through the master
branch.
[1]: d6afa9f325closesodoo/odoo#161568
X-original-commit: e664b2367f482aa6edc492db16ec92ffff1ac0a1
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
The goal is to modify the acconuts that take please in those entries.
A typical example is a company that wants to recognize cost of goods
sold for the input and output at the same time, instead of waiting
for the customer invoice.
closesodoo/odoo#161505
X-original-commit: f477433a9092deb21236b90114759316b13bc1bc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
After `_check_combo_inclusion` was added, it broke product creation for
users without sales rights (e.g. stock managers). This commit fixes
the issue by using `sudo().search`.
closesodoo/odoo#161313
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
[This first commit] made it possible to have an error when there was no
comparator for a field with conditional visibility. [This second commit]
prevented an error from occurring in this case. The purpose of this
commit is to prevent the user from getting a conditional visibility
configuration for a form field where there is no comparator.
Steps to reproduce the problem:
- Go to /contactus.
- Edit page.
- Click on the "Your Company" field.
- Select "Visible Only If" for the "Visibility" option.
- Click on "Visible Only If" again.
=> The comparator is not defined.
Another way to have the issue was:
- Drop a form on a page.
- Click on the "Your Company" field.
- Select "Visible Only If" for the "Visibility" option.
- Set visible only if Your Name is equal to "test" as condition.
- Click on Your Name field.
- Change the field type to Radio Buttons.
=> The comparator is not defined.
This commit fixes those two cases.
Technical information:
When we change the field's visibility to conditional (`setVisibility`),
we add a default visibility dependency (`_setVisibilityDependency`). At
this point, the comparator is removed and added in `_renderCustomXML`.
`_renderCustomXML` was only called if the visibility dependency had
changed.
[This first commit]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
[This second commit]: https://github.com/odoo/odoo/commit/808780c89cfba940957f7410f787de31e31bda27
opw-3806409
closesodoo/odoo#161527
X-original-commit: 770cc162d6de82818d8e29bf156bb01f65ca8e2c
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Prior to this commit, splitting an order would create a new order,
causing it to appear again on the preparation display. This could
lead to the kitchen preparing the same order twice. The sequence of
events was as follows:
1. The order is placed.
2. The kitchen receives and prepares the order.
3. The waiter delivers the order to the table.
4. The client receives the bill and requests a split.
At the point of splitting, a new order is created. This duplicate order
should not be sent to the kitchen as it represents a meal that has
already been prepared and consumed. This commit resolves this issue by
preventing display of duplicate orders to the kitchen during order
splitting.
Enterprise PR: https://github.com/odoo/enterprise/pull/60537
opw-3809693
closesodoo/odoo#161498
Related: odoo/enterprise#60537
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Issue:
======
traceback when clicking on gradient colorpicker in mass_mailing
Steps to reproduce the issue:
=============================
- Got to email marketing
- Add some text
- Select the text and go to graadient and activate custom
- click any color in the colorpalette -> traceback
Origin of the issue:
====================
Some colorpickers are created inside the snippets sidebar and then gets
removed by `_updateRightPanelContent` in `SnippetsMenu` so the owl
components corrosponding to them will have `this.el = null` which will
cause a problem when updating the props since we will use it in the
update.
task-3834112
closesodoo/odoo#161275
X-original-commit: 9ccd820813f6c0bd7608e80570a6999577aff513
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Context
In a previous fix https://github.com/odoo/odoo/pull/83276
, the `_notify_get_reply_to_formatted_email` method was introduced
to prevent edge-cases where the cypthon `email` library might incorrectly
fold the “Reply-To” email header.
We identified an other corner case where DKIM signature verification
might fail on the recipient’s end depending on the tech stack used to
verify the DKIM signature vs the one used to DKIM sign it on the
sending end.
This might be related to how RFC5322 and RFC6376 interact with each other :
In RFC5322 defines folding white spaces as follows :
```
FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
with obsolete FWS = 1*WSP *(CRLF 1*WSP)
```
While RFC6376 uses :
`FWS = [*WSP CRLF] 1*WSP
`
Based on this, it seems that for proper header content folding,
the specifications expects at least one WSP (space or tab) before a CRLF.
Currently when using the `email` cpython library to handle email
objects, we observed that when the header value for the “Reply-To” is
longer than 68 characters, it will return a folded string representation
adding a linebreak after the colon.
Example:
`Reply-To:\r\n "Marc R.Long Name Jonhson" <catchall@very.long.subdomain@example.com>\r\n`
Notice that the there is no WSP between the colon character an `\r\n`.
It seems that in this corner case, certain DKIM verification tech stacks
(from tests Microsoft Outlook and Rspamd) will miss-read the “Reply-to”
header as empty, while others correct for it (Gmail). This in returns leads
to the DKIM signature verification failing.
As it is impossible to test every possible combination of DKIM tech
stacks in the email ecosystem and that until the `email` cypython library
handles this corner case correctly, this fix tries to preformat the
“Reply-To” more defensively.
We also print a warning log if the `record_email` alone is longer than
68 characters (as it will not be folded), inviting the user to shorten
it to prevent DKIM verification issues.
Unit test fixing:
- shortened alias name to prevent the 68 character
limit from being triggered during the test_notification_reply_to_batch
performance test (as we are not testing the 68 char here)
- changed language in test_mail_message_values_fromto_long_name
to reflect the new 68 character limit and mutted
logger, as it now print a warning message
Considerations for the future
This PR only prevents the “Reply-To” from being malformed. In theory,
the miss-folding could happen to any email header constructed using the
`email` cpython library. In practice, the probability of the “To” and
“From” being affected is low, as they usually don’t exceed a total of
78 characters as per RFC.
Nevertheless if the future shows that this might be a bigger issue, one
should think about:
* On Odoo side: add a more robust header value formatting applied to all
affected headers before the email gets sent out
* On Python’s side: work with the `email` library maintainer to find a
longterm solution
opw-3826296
fixed test and conflicts in 17.0 FW
closesodoo/odoo#161014
X-original-commit: 894f981d04195861e757c052b7d10155cb5975b4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
**Current behavior:**
Entering kiosk mode in the webclient in a multi-company env
will display the logo of the default company.
**Expected behavior:**
The logo on the kiosk screen will belong to the currently
selected company.
**Steps to reproduce:**
1. Make a second company, give the default company and the new
one distinct logos
2. Select the second company from the company selector menu
3. Enter kiosk mode in the Attendance app, observe the logo
is that of the inactive company
**Cause of the issue:**
After arriving at the URL route for the kiosk page from the
_action_open_kiosk_mode() method, the context has been rebuilt
to a somewhat default state which no longer informs the current
company id. `self.env.company` references the default company of
the user.
**Fix:**
Add an id slug in the URL route which identifies which company's
kiosk we should be seeing.
opw-3802916
closesodoo/odoo#159702
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
STEP TO REPRODUCE:
=================
* Unistall hr_org_chart application
* Click on hr application
You will have an error due to the missing hiercharchy view.
closesodoo/odoo#158523
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Steps to reproduce:
-------------------
- create a storable product and set a quantity on hand
- create a delivery for this product and set to draft
- add a demand for this product on the delivery
- click on "Mark as Todo"
- go to the product form
- click on the Forecasted smart button
- click on "Unreserve" button (to process business logic ans reload report)
Issue:
------
The report is reloaded with all products.
Cause:
------
When we setup/start the `StockForecasted` component, if we can't find an active model
in the action's context, we try to find it in the action's props
(via res_model or on the original action if necessary).
If the original action is used, the active model must be
in the context of the original action.
Unfortunately, this is not the case.
Without `resModel` the domain determined in the `graphDomain` method
will not filter on the product (which corresponds to the `active_id`).
Solution:
---------
If no resModel is found via the context, add it to the context
when it is determined.
Add the action id to handle the case of reloading the page
directly via the browser's refresh button.
opw-3793065
closesodoo/odoo#161569
X-original-commit: 288e1e0f8d7bc343b90a22692bdf44ccb9b21725
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
When generating the PDF, the translatable fields (the note of the
payment terms, the name of the products, etc) will use the language set
on the partner_id of the invoice.
The xml generated should do the same.
opw-3842885
closesodoo/odoo#161543
X-original-commit: a1afcc896fa61db561eb7be6624083ac4ee11a4b
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, you cannot send a credit note to Facturae if it was created
from a paid invoice
Steps to reproduce
------------------
* install `l10n_es_edi_facturae`
* create an invoice and register its payment
* created and confirm a credit note from your invoice
* attempt to send that invoice to Facturae
You should be met with the following traceback:
`psycopg2.ProgrammingError: can't adapt type 'account.move'`
Cause
-----
In the function `_l10n_es_edi_facturae_get_corrective_data()`, there is
an attempt to browse the output of a call to
`_l10n_es_edi_facturae_get_refunded_invoices()`. This function is
expected to return a mapping of id to id. However, in certain scenarios,
it may return a mapping of id to recordset instead.
opw-3811170
closesodoo/odoo#161549
X-original-commit: a0172cb5f8efc35c4138aadc56beebca328457f4
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
This reverts commit 436c1c6.
The commit was fixing an issue where the product configurator dialog
would not be shown for custom attribute, no variant, and dynamic
attribute using the quick buy add button on the '/shop' page.
The commit introduces an undesirable behavior: the product configurator
would always be open if customers choose none of the multi-checkbox
options.
closesodoo/odoo#161144
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, when a DM chat had a custom name, the
search was not taking it into account.
Steps to reproduce:
- Log in as Mitchell Admin
- Open a DM chat with Marc Demo in Discuss app
- Rename conversation to "Test"
- Open more than 20 chat/channels (can create 20 channels)
- type "Test" in the quick search of discuss app sidebar
=> The DM chat with Marc Demo is not visible in filtered sidebar.
This happens because the quick search was relying on `thread.name`,
which actually only matches exactly the UI when this is the name
of a channel or when a group chat is explictly named.
The actual thread field used that matches textual name of thread
is `thread.displayName`, and this field is synced with custom DM
chat if any.
closesodoo/odoo#161540
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This lead to some error in the Mexican EDI.
Suppose 2 lines of 17983.80 with 16% tax.
17983.80 * 0.16 = 2877.408
2877.408 * 2 = 5754.816 ~= 5754.82
If we distribute, 2877.408 becomes 2877.41.
However, the government allow the value to be between 2877.408 & 2877.409.
closesodoo/odoo#161487
X-original-commit: 84f7ddc5a029a25524d58867ae4a5497de907d5a
Related: odoo/enterprise#60532
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Clean up field value when is not used, this because is only
show when some conditions applies, if not we need to clear it to
avoid having wrong data on taxes.
We want to behave as an onchange, to se change the field to a compute
one, in this case stored and also can be edit by the user
closesodoo/odoo#156808
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to Reproduce:
- Install Project App
- Go inside any project and set the state of task as done
- Click on project burger menu and click on settings
Issue:
- The count on the stat button refers to count of all tasks
Causes:
- Reference of wrong field in the XML i.e ., 'task_count' instead of
'open_task_count'.
Solution:
- Changing the field to reference it to open tasks count i.e., 'open_task_count'
task-3741260
closesodoo/odoo#153984
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The payment with MobilePay payment method failed due to the wrong code.
opw-3859956
closesodoo/odoo#161481
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Fixes a few things:
- A couple placeholders existed for non-required fields, which means in
certain cases they would be printed in real reports (i.e. not just
shown in studio)
- hide the UoM from the deliveryslip when the setting isn't active
(this is broken in earlier versions too, but fix can be backported if
someone finally complains about it since it's been there for awhile)
- Updates a placeholder that was confusing (a location instead of a
package name)
Note only `stock` reports were checked for this fix, there are probably
still other problematic reports.
See PR: https://github.com/odoo/odoo/pull/129310 for reference of when
placeholders were added in
closesodoo/odoo#161420
X-original-commit: 90104d0133ab54ac12e466c6187601029e50b4d9
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
This commit adds the requirements in order to add the bidimensional code
on the receipt of the point of sale for the Chilean localization.
closesodoo/odoo#161342
Task-id: 3747828
Related: odoo/enterprise#60451
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Current behavior:
If you change the expected duration of a workorder, then move the
workorder to another workcenter, the expected duration is recomputed to
but the finish date is not adapted. This leads to an inconsistency in
the gannt view. Visually it will look like the duration expected has not
changed because the date are still the same.
Fix:
To fix this we make sure that the finish date is recomputed when the
expected duration is modified. This way both date and expected duration
are consistent.
Steps to reproduce:
- Create a product with a BOM
- The BOM should have at least 1 operations with a duration of 1 hour
linked to a workcenter
- Create a manufacturing order for this product, confirm and plan it
- Go to the planning by workcenter
- Change the duration of the workorder by sliding its finishing date
- At this point if you click on it the duration should have changed
- Move the workorder to another workcenter
- The duration has been recomputed, but the finish date is not adapted
(You can click on the workorder to see the duration has changed)
opw-3717361
closesodoo/odoo#161297
X-original-commit: 2c70160daa31736b0ab8d22f6c99c76bfa9c7301
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Currently, when the company has a french localization and activates the qr code option on the pos bill, if a customer scans the qr code, he will 'inevitably' meet an error:
> According to the french law, you cannot modify a point of sale order. Forbidden fields: date_order, user_id, lines, payment_ids, ...
Steps to reproduce:
-------------------
* Install **France - Accounting**
* Switch to `FR Company`
* Go to the app **Point of Sale**
* Select **Configuration** > **Settings**
* Enable `Use QR code on ticket`
* Open a shop session
* Add anything
* Select/or not a customer
* Select **Payment**
* Select any payment method then validate
* Scan the qr code on the ticket
* Try filling the form and saving
> Observation: Error
Why the fix:
------------
We understand the confusion for french localization users to be presented with a feature which they are not able to use as intended. The Qr code feature was implemented to make it easier and quicker at the cashier but will always end up in an error, unless a client was selected and the invoice was created when validating the payment at the register. But then, it doesn't save time.
Since they are not able to use the feature as intended, we decided to make it unavailable for companies with a french localization.
There has been a lot of discussion about how to solve this issue. However, a lot of the ideas discussed were not doable instable versions and this is the only solution we agreed on.
opw-3704767
closesodoo/odoo#160884
X-original-commit: 6c64c30edbcc660738e66baa46646a3909a93c09
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
This commit allows the user to search a specific quant in the detailed
operation view via the display name build from its characteristics
For instance, searching 'LOT1' will search for quant having
location or lot_id or package or owner equals to 'LOT1'.
closesodoo/odoo#141527
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Currently, when there is only one loyalty program available for an
order, we apply it automatically without opening the wizard. This is a
problem when the reward is a free product among all with a specific tags
because the user can not choose it (it takes the first one by default)
We now automatically apply only when there is only one reward possible
opw-3774944
closesodoo/odoo#161442
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Steps to reproduce
------------------
* install l10n_es_edi_facturae
* create and confirm an invoice
* click on 'Send & Print'
You should see that you are unable to uncheck 'Generate Facturae edi
file'
Cause
-----
In 0d3d6c8, `l10n_es_edi_facturae_checkbox_xml` changed to a non-stored
and read-only computed field.
Fix
---
A proper fix would consist in making the field
`l10n_es_edi_facturae_checkbox_xml` stored. But we can't do that in
stable. So we make it `company_dependent` as a workaround.
opw-3772085
closesodoo/odoo#161433
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to reproduce:
-------------------
- create a partner which is "individual";
- create a project (with timesheets and billable);
- create a task A with timesheets;
- link the task A to a sale order line with the partner created;
- create a sub task A in task A with timesheets;
- remove the sale order line linked to sub task A;
- change the partner to "Company"
Issue:
------
The sale order line is added to subtask A.
The sale order to the partner will not be correct.
Cause:
------
We trigger the logic `_compute_sale_line` when the `is_company`
of the partner is modified.
This is due to the construction of the dependencies,
which takes implicit dependencies into account.
Solution:
---------
Remove the dependency and keep only the dependency
with `partner_id` because it is an ORM limitation.
opw-3836986
closesodoo/odoo#161305
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
- Open the 'project.milestone' form view.
Issue:
- Excessive space exists between quantity and unit of measure in the
'project.milestone' form view, impacting the layout.
Solution:
- Reduce the space between elements to improve the layout and enhance
the user experience.
closesodoo/odoo#161256
Task: 3549267
X-original-commit: 8f3418d32e006a64f53361a38efdc30f6f706fc3
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
On pages without visible dropzones (including if one exists in a
currently invisible snippet), snippets should not be droppable from the
editor. Up to now, the behavior did not take into account invisible
snippets, leading to confusing situatons (cf. steps to reproduce).
This commit makes sure that the drag & drop is disabled if the only spot
available is within an invisible snippet. It reenables the D&D if an
invisible snippet is shown.
Steps to reproduce:
- Go to `/web/login` and edit the page
- Most snippets can't be dragged & dropped
=> Good. There is no dropzone for them.
- Activate the cookies bar in the settings
- Go to `/web/login` and edit the page
=> The "structure" snippets can now be dragged & dropped, even though
the only place where it is possible is the cookies bar, which is
invisible. It looks like a bug for the users who try to drop blocks on
the main page and cannot.
opw-3829660
closesodoo/odoo#161210
X-original-commit: 58af56c57ca935913e81517f4a17c6b34c262301
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When user deletes line of journal items and tries to save invoice,
a traceback appear.
Steps to reproduce the error:
- Create a new invoice > add 1 product > Save
- Go to journal items > delete 1 line
- Change currency > Save
Error: A traceback appears:
'ValueError: not enough values to unpack (expected 3, got 2)'
https://github.com/odoo/odoo/blob/6768cf06138bb5c94a6c77db79ed5d802333b290/addons/account/models/account_move.py#L2422
Here, vals['line_ids'] have 2 values, so for 'line_vals' there is no value.
So when user tries to save invoice,
It will lead to the above traceback.
sentry-5119406548
closesodoo/odoo#160266
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Due to the project user's inability to create a task stage, we have removed the
'create stage' option from the kanban view.
task-3511164
closesodoo/odoo#159557
X-original-commit: cadf1483948295397137284a01ddf219169bcecd
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The `stock.move:_action_done()` already reserve the next mto moves at
validation. Calling the reservation method after the validation again
may lead to unwanted results like calling `check_entire_pack()` and
messed up the result_package_id on the stock move lines.
Task : 3764822
closesodoo/odoo#161445
X-original-commit: 2551f735e24eb2549264b0a70b814be8d3c52922
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue
-----
The cache is not updated properly when the configuration of a currency changes.
This leads to reading stale values in other places. For instance, changing currency
symbol position isn't reflected in invoice tree views unless after a server restart.
Steps
-----
- Open Accounting -> Configuration -> Currencies.
- Pick the active currency, say USD.
- Change 'Currency Symbol Position' to a different value.
- Go to Accounting -> Customers -> Invoices. The displayed amounts don't reflect
the change.
Cause
-----
Cache refresh was misplaced after a premature return, so the cache wasn't refreshed
when 'digits', 'position' or 'symbol' fields of `res.currency` are written, although
that was the intent.
opw-3849155
closesodoo/odoo#161036
Signed-off-by: Moataz Hussein (mohu) <mohu@odoo.com>
`compare_list_price` wasn't updated when the user changed the website's currency. Now, it's
converted to the website's currency.
This change also makes the conversion of `price_extra` and `list_price` safer by fetching both the
`from` currency and the `from` amount from the same record.
opw-3845887
closesodoo/odoo#161428
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Create an invoice with analytic_distribution.
Go to account.move.line, select the line with analytic_distribution, click on action 'Move account'
validate
--> Issue the analytic_distribution is not reversed
closesodoo/odoo#161394
X-original-commit: e7f5bfc6a685ec9809c13290d1432888c3aad47c
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Co-authored-by: Laurent Smet (las) <las@openerp.com>
Before this commit, when adding a new grid item in a grid by using the
"Add Elements" option, if the page was scrolled such that the top of the
grid was not visible, this new grid item may not always be visible. This
is annoying as the user could add an element and not see where it
appeared and would therefore need to look for it.
This commit fixes this by making the page scroll to the added grid item
if more than half of it is not visible. A test is also added.
Steps to reproduce:
- Drop the "Text-Image" snippet and enough snippets under it to have a
scrollbar.
- Toggle the "Text-Image" snippet to grid mode.
- Scroll the page so the top of the grid is not visible.
- Add a new "Button" with the "Add Elements" option.
=> The button is not visible.
task-3616138
closesodoo/odoo#161159
X-original-commit: 50766b74196b3cdc5ac83d7962873f4fffa4c9f6
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
This commit fixes a traceback that occurs when calling `getValue` on
`wysiwyg` while the `odooEditor` instance variable is not defined for
whatever reason.
task-3600667
closesodoo/odoo#161110
X-original-commit: cb2c51aa28ade702a87bbdbb3b4eb9157a56b409
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
-Step to reproduce: create a custom module and try to extend method in
website_slides controller like this:
@http.route(sitemap=sitemap_slide_view)
def slide_view(self, slide, **kwargs):
return super(WebsiteSlidesSeo, self).slide_view(slide, **kwargs)
From there, 'rule.endpoint.original_routing' will take the value from
the extend method not the original one therefore user will one again go
to the the forbidden error page which is'n friendly. We shouldn't access
original_routing because that's the "function's specific @http.route"
closesodoo/odoo#160864
-solution: we only need rule.endpoint.routing because it is the one holding the "merged @http.route accross inherited controllers".
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
When importing an invoice from a Factur-X format a payment reference is now read from correct field. From the same field where the original payment reference is exported.
closesodoo/odoo#157811
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steuernummer was being validated at tax report xml generation. The check was moved to the company form view.
Moreover, the field was set visible in the company form view for multivat.
It should be a constraint raising when trying to set the steuernummer to the company; there is no point in only checking it at XML generation.
task-3809218
closesodoo/odoo#161423
X-original-commit: c8543f716164d9e1f7e5b39908ff9805c9cc53bd
Related: odoo/enterprise#60496
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Hesham Saleh (hsal) <hsal@odoo.com>
steps to reproduce:
- Go to Accounting > Accounting > Actions > Lock Dates
- Set a Tax Return Lock Date to a date of the previous month
- Create and confirm vendor Bill with a taxed line of positive price
- Go to Accounting > Reporting > Audit Reports > Journal Report
- Hover over the Vendor Bills and click on "journal items"
- Add the optional vehicle field to the recods
- Select your expense line and try to add a vehicle
> Invalid Operation "You cannot modify the taxes related to a posted
journal item..."
Cause of the issue:
Modifying the "vehicle_id" of the account move line will trigger a call
of the `_sync_dynamic_line` method in order to modify other account move
line linked to the same account move:
https://github.com/odoo/odoo/blob/6a4808802c67f98696338d0b6f6a07934c8003fb/addons/account/models/account_move.py#L2285-L2287
During the call of this write method, the account move line that we
did not directly modified will not be excluded:
https://github.com/odoo/odoo/blob/6a4808802c67f98696338d0b6f6a07934c8003fb/addons/account/models/account_move_line.py#L1571
as `..._field_will_change(line, vals,"vehicule_id")` will be `True`.
The error will therefore be raised two lines later because a 'tax_id' is
present in vals as a 'tax_id' was set on our related account move line.
Expected behaviour:
Since the 'tax_id' present in vals is the same as the one already set on
our account move line, we are not modifying the taxes related to a
posted journal item and we should not raise the error.
opw-3810718
closesodoo/odoo#161387
X-original-commit: 3cd87c61c852eef96195a39a4011a6baa39e3078
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Only delivery carriers that can communicate with the outside should be deactivated.
Every time a database is neutralized, all delivery carriers are deactivated. In staging or test databases this should not be the case, only delivery carriers with an external connection, i.e. delivery carriers with an external provider should be deactivated.
Delivery carriers with fixed price or based on rules should not be deactivated with every neutralization. This way Odoo can continue to operate with shipping methods without prejudice to the users in neutralized databases.
@moduon MT-5612
closesodoo/odoo#161182
X-original-commit: bdaeae0230fe0da7743f8cc4ed9dcb210b994540
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Issue:
- when creating an accrual plan based on attendance,
the duration is not computed accurately when allocating.
- the computation is not correct if you select a different
start date in the allocation without emptying the field "Allocation"
Steps To Reproduce:
- In the time-off app create an accrual plan: where employee
accrue 1h for every hour worked based on attendance.
- In the attendance app create a new attendance for 8 hours.
- add a new allocation to Mitchell Admin with the plan you created.
- Change the date on the validity period, new allocation is 8h.
- change the date again and notice the Allocation not computed correctly.
Solution:
- In `_onchange_date_from` when simulating how many days an
accrual plan would give from a certian `date_from` we don't reset
`number_of_days` to 0. reseting it to 0 fixes the issue.
opw-3793961
closesodoo/odoo#160696
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
