Incorporate Andrea Geraldo (AndreaGeraldo) as Vauxoo's contributor.
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#131860
X-original-commit: 76dd1770774b2c20311e5df6f2a73a35f67d028a
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The `_l10n_sa_get_invoice_content_edi` function is used to download the
edi_content of an edi_document when this edi_document is in error. This
function should return the xml encoded as a bytes, as it is then encoded
in base64 in account_edi/models/account_edi_document.py otherwise a
closesodoo/odoo#131837
Typeerror: "a bytes-like object is required, not 'dict'" is raised.
X-original-commit: 8bf1d6e0abdd41211045d23a512be5269a7d1b0c
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
This commit avoid a reset of the groupby filter applied in a kanban view
when a non-empty column of this view is deleted. This issue was
introduced by the conversion of the kanban view to
owl (https://github.com/odoo/odoo/pull/92475). It was fixed in master,
hence this commit only adds a test.
Steps (in saas 16.3)
=====
- Install module project with demo data
- Go to the kanban view of a given project (e.g. Office design)
- Group by Personal Stage
- Remove a non-empty column
Issue
=====
- After the reload of the view, the groupby is reset to the default
one (but the groupby filter is still the same in the control panel)
Cause
=====
The parameters of the view are not correctly passed/used to/by the
method load of RelationalModel.
Fix
===
Checking that the groupby field is not already set in load before
resetting it to its default value solves the problem.
task-3358595
closesodoo/odoo#131835
X-original-commit: af4be5ff868c106e854df3753ad9c147e718225d
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Previous fix c7616df enforced an order on the workorders for the
computation of the time_cycle. However, 'asc' is used by default in
order clauses if not explicitly written.
This resulted in using the oldest workorder instead of the newest to
compute the duration.
closesodoo/odoo#131830
X-original-commit: a69d13abbc81b36aaf717f8e4d665fda8580c1fc
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Before this PR, scrollbar in livechat session history was horizontal because the
flex-flow was set to column.
This PR remove the flex-flow to fix the issue.
task-3383919
closesodoo/odoo#131611
X-original-commit: ac3275706bbc3fcc1bffea731973de850db74892
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Steps to reproduce:
- Get Field Service app and the module for cutom worksheets.
- Create a new worksheet template that contains images.
- Create a new task with this template and go to the worksheet.
- Add any image.
Forcing the width to 100% breaks the view in safari since it's not going
to respect the proportions, removing this will have good behavior in
both safari and other browsers (chrome, firefox), also this
will have the same behavior it used to have in 15.0.
Be careful with adding this back in the future since when a user adds
inside his worksheet an image field, studio set the default size to
"small" value. (It's added an inline style with a widthset as "auto" and
a height set as "90px") but the image_field API was broken with the
w-100 added here[1]. It's seems not needed so we remove it to fix the
api.
[1]: https://github.com/odoo/odoo/commit/d1de396f2aa91a03732f0447d59a7306acae3129#diff-a9fcda7725e1ce88ca6deed7aff792476b26e264edc757b889e9dd3b94ea1dbfR33
opw-3415267
closesodoo/odoo#131808
X-original-commit: 740b560284e5c0987854f173437d7e4b3454caf5
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
Steps to reproduce:
- Create any emv_qr_code. Set merchant name with a Vietname accent
- Set amount to a integer number
Current behaviour:
- An EMV QR Code will be generated with accent merchant name, and the amount
include .0 value
Expected behaviour:
- The EMV QR Code change change the accent value to alphabet. And the amount should
not contain .0 if the amount is an integer
closesodoo/odoo#131852
X-original-commit: 158f8090ef30065b97ebe8b15b0bf73fff6a9ac4
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Tommy Ng (tong) <tong@odoo.com>
Steps to reproduce
------------------
* install l10n_de
* switch to a german company
* create an invoice
* add a line such that the account's default tax is different from the
tax set on the line (ex, account: `8400 Erlöse 19% USt` and
tax: `7% Umsatzsteuer`)
Attempt to confirm the invoice, you should see that you can't. The
system requires the account's default tax to be the same as the tax set
on the line. This should not be the case. It's a practice in Germany to
link a tax to an account like this, but it's not a legal requirement.
opw-3324323
closesodoo/odoo#131779
X-original-commit: 4de4a099296be150a8e75ffdbf1321cdee75137c
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Currently, the form view of the account.account has a fixed width for the
account name field which can lead to longer account names to not be readable
as they are not displayed entirely.
This PR allows users to resize the width of the name field to the length
they want without letting them exceed the maximum of the page. This makes
the field keep a shorter width for shorter account names while being able
to be longer for accounts which name is longer.
The account name field has now a width which can be adapted by the user so
he can read both sort and long account names.
task-3441547
closesodoo/odoo#131312
X-original-commit: aa536bbf1cecbdc0ffbc3d44c20ed81afa5565b2
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Thomas Becquevort (thbe) <thbe@odoo.com>
l10n_sa_edi uses account_edi methods but has no dependency
on it.
closes odoo/odoo#131845
Related: #130836
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
The _prepare_edi_vals_to_export functions on account.move and
account.move.line must be moved to account from account_edi.
Account_edi_ubl_cii does not depend on account_edi anymore,
and needs them.
closesodoo/odoo#131801
Signed-off-by: Josse Colpaert <jco@odoo.com>
Prior to this commit:
When we open the portal view of the project which is project sharing and search
in a project, we have two different filters for searching sale orders and sale
order item which is unnecessary. Hence we can make the search resourceful by
combining both filters just like the working of sale order filter in the Search
View of the project.
Post this commit:
Combining both filters under the name sale order to make a seamless search.
closesodoo/odoo#131810
Task: 3391908
X-original-commit: fb31cea2aeb666e71f49b4f99813bf592a96d6b2
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, updating recurring events was troublesome due to an Outlook limitation, which was sending spam to attendees. After this commit, when updating recurring events, it is suggested for users to update recurrences directly in Outlook Calendar to handle this limitation. It is not allowed anymore creating recurrences in Odoo when the sync with Outlook is active (although recurrences created in Outlook are still synchronized in Odoo). Recurrent events that were created before the synchronization start (which are not synced) can still be deleted in Odoo (then a suggestion of recreating them in Outlook is shown).
Previous unit tests regarding the synchronization of recurrences from Odoo to Outlook were deactivated. New tests were added asserting the forbiddance of this recurrence creation and update flow.
closesodoo/odoo#131806
Task-id: 3204905
X-original-commit: 27ee51029c1d4e9164b9705306b59b26598bcf7e
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
Problem
---------
When deleting a tax repartition line, an error occurred. When popping
the modified values during deletion, only two values were present in the
modified values. Thus, unpacking to 3 variables resulted in an error:
`v` did not exist.
Objective
---------
Make repartition lines deletable again.
Solution
---------
Instead of popping 3 values for every command, we pop 1 stored as a
list. We access the relevant elements using the index when necessary.
task-xxxxxxx
closesodoo/odoo#131799
X-original-commit: bbb76c6e5cc9936321c2ec4235a78446f45250f5
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Antoine Boonen (aboo) <aboo@odoo.com>
Steps to reproduce:
- Install website_sale
- Go to website shop in the frontend
- Login, Edit
- Click on 3rd or 4th kanban item
- Push down
Issue:
The item goes to the end of the list instead of moving one element to
the right/down. Pushing an element down searches for the next element
with a higher `website_sequence` and places the current element right
after, by switching their sequence values.
Normally the logic works fine, but the problem arises when the
`website_sale` module is installed, when records with
`website_sequence = NULL` are set to the same default value, namely
10000. Then, when an item with `website_sequence = 10000` is pushed
down, it will skip many items, before finding one with a higher
`website_sequence`.
Solution:
When updating records with `website_sequence = NULL`, assign an unique
sequence to each one. We can set the `website_sequence` relative to the
inverse of the id to ensure that the order on the shopping page remains
the same as it was prior to the fix.
opw-3318867
closesodoo/odoo#131496
X-original-commit: 6d3d64b480928472fe94ed80f8cc983c88b085e8
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Steps to reproduce the bug:
- Create a storable product "P1"
- Add 2 variants:
- Color: Red and Blue
- Size: XS and M
- Create a Bill of Materials (BoM):
- Add any components
- Create operation "OP1":
- Apply only to: Red XS
- Create operation "OP2":
- Blocked by "OP1"
- Apply to all variants
- Create a MO with the variant "P1 (Blue and M)"
- Try to confirm the MO
Problem:
a traceback is triggered, the issue has been fixed in: https://github.com/odoo/odoo/commit/0f21fde26fa4387d93722092ebf21d294fcfcd4f
Solution:
Link only if an operation is blocked by another operation with the same attribute values.
OPW-3329263
closesodoo/odoo#131727
X-original-commit: 2fa8e2f64292483c0aa27141fe59eb4a6ff8effb
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When user pass the domain value as ['acc_number', 'ilike', ''] . The value of
variable 'value' is passed as False and at the time of concatenate with the
string traceback will be generated.
'can only concatenate str (not bool) to str'
This commit will check the condition if the value of variable 'value' is set or
not.
sentry - 4194332917
closesodoo/odoo#131726
X-original-commit: 60067a1cf69960d87f88520e54be6772056f3b40
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
When user uninstall the module 'Manufacturing' the relevant records are not
deleted from the Operation Types, Transfers and Stock Rules.
To produce in sass-16.2:
- Install 'Manufacturing' module
- Create mrp order and validate it.
- Now uninstall 'Manufacturing' module.
- Operation Type 'Manufactuing' is still showing. (14.0 to master)
- Go to 'Inventory' and click on 'Receipts' and remove all the filters.
- Another way > Create a new 'stock.picking' with 'Operation Type' as
'Manufacturing'
Error: A traceback appears: 'Wrong value for stock.picking.picking_type_code:
Manufacturing'
Fixed this issue by updating the code of the picking type and archiving it after
uninstallation of module using 'ondelete' function.
sentry-4167898386
task-3318858
closesodoo/odoo#131725
X-original-commit: 0b400d33ed9ad15d539306ff7ba8519afc63234c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When user uninstall the module 'stock_dropshipping'. The value 'dropship' for
selection field 'Type of Operation' does not get deleted and cause error.
From version 14.0 when user uninstall the module 'stock_dropshipping', record
does not get deleted.
To reproduce the issue in sass-16.2:
- Install 'stock_dropshipping' module
- Go to 'inventory' module
- Go to 'Dropship' and click on 'NEW'
- Make sure 'Type of Operation' is 'Dropship' and save
- Uninstall 'stock_dropshipping' module.
- Go to 'Inventory' and click on 'Receipts' and remove all the filters
- Another way--> Create a new 'stock.picking' with 'Operation Type' as 'Dropship'
Error: A traceback appears: 'Wrong value for stock.picking.picking_type_code:
'dropship'
Fixed this issue by updating the code of the picking type and archiving it after
uninstallation of module using 'ondelete' function.
sentry-4167898386
X-original-commit: ee281cf59d25e7e33f08022784f390e8eb798324
Part-of: odoo/odoo#131725
Create account 400000 Product Sales and 4000010 Product Sales 2
Create two Sales Journal:
- INV1 with allowed accounts: 400000, 121000, 251000
- INV2 with allowed accounts: 400010, 121000, 251000
Create an invoice with INV1, add a line with account 400000, Save
Now change the journal in INV2, account on the line to 400010, Save
Issue: Action will be blocked because of the failing constraint, which
is checked after the move write but before the line write so we have
mismatching journal and account
opw-3274843
closesodoo/odoo#131721
X-original-commit: 2529903d942ce0275fc072af6b9785aebbe98071
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
During the test, the rate are created on UTC timezone.
However the test could be run with a different timezone.
Since the rate doens't have a name, by default they have the
create date name. However due to timezone difference, it could
be different day and the newly created rate for the test will be
filter out
closesodoo/odoo#131708
X-original-commit: 300fe8ad36163b6ad7f8a37ac26b014c1510d64f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
As sub-tasks are a sub-set of a task that should logically be completed
for the parent task to be completed, it would make sense for the
sub-tasks to share the same milestone as their parent task by default.
The milestone of a parent task is automatically set to its subtasks if:
- The subtask has no milestone set
- AND They belong to the same project or the subtask has no project set
- OR they shared the same milestone before the change on the parent
task (side effect for that case: if an invalide milestone is set on the
parent task, both parent task's and subtasks' milestones which are equal
are gonna be reset)
task-3450281
closesodoo/odoo#130439
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, the element returned by the function
renderToElement, it was still attached to the parent <div> added in the
render function.
Now, the element returned is detached.
Part of task~3443861
Part-of: odoo/odoo#130467
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
As all templates are now rendered with ow engine, we need to replace
qweb.has_template with it's owl equivalent.
Part of task~3443861
Part-of: odoo/odoo#130467
As all the templates are now imported in the owl app, the templates must
comply to owl.
range is not in the rendering context on owl, so instead of using it, we
use Array.
Part of task~3443861
Part-of: odoo/odoo#130467
As all the templates are now imported in the owl app, the templates must
comply to owl.
t-set of a property of an Object is not allowed in owl.
Part of task~3443861
Part-of: odoo/odoo#130467
This commit removes the qweb.render method, instead it will use the owl
render engine (renderToString or renderToElement).
Part of task~3443861
Part-of: odoo/odoo#130467
This commit removes the qweb.add_template method, which was used to
add a template to qweb. Now we add the templates to the owl app.
Part of task~3443861
Part-of: odoo/odoo#130467
As all the templates are now imported in the owl app, the templates must
comply to owl.
t-key is mandatory when using a t-foreach
Part of task~3443861
Part-of: odoo/odoo#130467
Before this commit, only templates with owl=1 were added to the owl app.
Now, all templates are added to the owl app, and none of the templates
is added to qweb.
Part of task~3443861
Part-of: odoo/odoo#130467
This commit ensures that files uploaded using the FileInput, upload
service or AttachDocumentWidget will not exceed the maximum file size of
the context in size before sending them to the server. It also moves
some utils from the formatters file to the numbers file so that one
can use them without requiring the view assets.
task-3390746
closesodoo/odoo#126914
Related: odoo/enterprise#45629
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
The limit was only enforced by the front-end, meaning that anybody could
forge a request with a huge file and get it processed by Odoo. According
to the documentation of werkzeug[^1], such limit should be enforced by
the server server instead of the wsgi application. It is the case for
Odoo Online but on-premise customers might not configure their servers.
The `web.max_file_upload_size` system paramter is now enforced upon
parsing the content of the request. It defaults at 128 MiB which is
enough for most documents and images. We do not want to host large
files (e.g. videos) in the Odoo filestore.
[^1]: https://werkzeug.palletsprojects.com/en/2.0.x/request_data/Fixes: #124646
Part-of: odoo/odoo#126914
Steps to reproduce the bug:
- Assume the current date is August 1, 2023.
- Go to general settings:
- set purchase security lead time: 20 days
- set manufacturing security lead time: 25 days
- Create a storable product “P1”
- Routes: Manufacture + buy
- Manufacture lead time: 1 day
- Create an order point:
- preferred route: Manufacture
- Quantity to order: 5
- Click on “Order once”
Problem:
A manufacturing order is created, but the "Scheduled Date" is incorrect.
Instead of being set to August 1, 2023, it shows August 7th.
The issue occurs because initially, we calculate the `Lead days date`
as follows:
Today's date (August 1st) + manufacturing security lead time (25)
+ Manufacturing Lead Time (1) = August 27th.
However, we use the purchase security lead time (20) instead of the
manufacturing so 27 - 20 = August 7th
To determine the exact date, we call the function
`_get_date_with_security_lead_days`. In which we try to get the
appropriate rule to use. However, in this case, the preferred route
of the orderpoint is not passed as a parameter to the function.
Therefore, we use the first rule of the first route ("buy"), and we end
up using its security lead time.
opw-3439546
closesodoo/odoo#130932
X-original-commit: 5726c8882ae92eca3adfe19500c109ef8bae38a2
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, the permission defined in Google Calendar of editing events by guests was always set in Odoo Calendar as 'True', even though there was also the 'False' option. This way, creating an event that didn't accept being edited by guests in Google and then updating it in Odoo by a guest was creating duplicates in Odoo Calendar and wrong lists of attendees.
After this commit, the permission of guests modifying the event is taken into account in Odoo Calendar. If a guest updates an event that doesn't allow updates, a warning is shown forbidding the update and the reason explained.
closesodoo/odoo#127397
Task-id: 3276829
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Steps to reproduce:
- Install Calendar App
- Create any meeting and go into mobile mode.
- Click on the meeting that we see in the calendar.
We are going to get a traceback since the latest update about the
calendar events popovers hasn't taken into account that we don't have
the same behavior in mobile, so whenever we try to get the popover
element in mobile we are going to get an error, so we check if we are in
mobile and we skip the popover reposition.
opw-3419973
closesodoo/odoo#131475
X-original-commit: 12310143b3cd9a871c763c70e7e1d6e5512ae0cf
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Before this commit, having two RadioField fields with the same values
was going to confuse them. When you click on the second, the first is modified.
Why:
The id used to link the label to the field's input was mistakenly
removed during refactoring. So we're going to put it back, and each radio
field will have its own id.
closesodoo/odoo#131663
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Before this commit, in a survey, opening a question, discarding it and then reopening it no longer displayed the content of the responses.
How to reproduce
In QuestionPageOneToManyField, we overwrite the behaviour of openRecord by reloading the record to be opened. This is no longer necessary since PR 129507 as the correct record is retrieved which already contains the updated values.
How to reproduce:
Go to a survey
Click on a question with answers
Click on discard
Click on the same question
Before this commit:
Response data not displayed
After this commit:
The answer data is displayed correctly
closesodoo/odoo#131662
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, editing a x2m record in a dialog then clicking on
the close button (X) does not discard the change.
How to reproduce:
- Go to a form view with an x2m in non-editable list mode
- Click on an x2m record to open it in a dialog
- Edit a field
- Click on the close button (X)
Before this commit:
The change is kept
After this commit:
The change is discarded
Part-of: odoo/odoo#131662
Before this commit, in the form view, clicking on an action in the menu
action executed the action even though the record save had failed.
Expected behaviour:
When you click on an action, you want to save the record and execute the
action if the record was saved without error.
How to reproduce:
- Go to a form view
- Create a new record
- Edit a field to ensure that the save returns an error
- Click on an action in the action menu (for example duplicate)
- The "Oh Snap" dialog opens
- Click on "Discard
Before this commit:
The button action code executes and displays a crash
After this commit:
The button action code does not execute
closesodoo/odoo#131660
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
The cause of the issue is that `datetimepicker('viewDate')` will return
the datetime of today by default event if the user selects nothing, to
remedy this, we now check if the user has chosen something before
storing the content of the field in `form_values`.
Step to reproduce:
- Install website_crm_partner_assign to have the "Partnership Date"
field on res.partner.
- Install website_sale to have the "Create customer" capability on the
website forms.
- Drag & drop a form snippet on any page
- Select "Create customer" as form action
- Add a custom field "Partnership Date"
- Submit the form without filling the Partnership Date field
- The field will be set to today's date while it should have been left
void.
opw-3333364
closesodoo/odoo#131614
X-original-commit: 0a5668d36cc43cf346c5aecb9236d690a6694a45
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Andrea Geraldo