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>
Before this commit, for products with attributes that do not create
variants but do carry additional costs per value, the discount
displayed on the PoS receipt inaccurately represented the price
difference based solely on the list price, excluding these additional
attribute prices. This commit corrects this issue to ensure that the
displayed discount on the PoS receipt and product screen accurately
includes any extra price from such attributes.
Steps to reproduce:
1. Create an attribute with "never" "Variants Creation Mode"
2. Add two attribute values
3. Add this attribute to a product and add an extra price
4. Enable "Discount on lines" on the user setting
5. Change the "Discount Policy" of the pricelist that is used in
the PoS to "Show public price & discount to the customer"
6. Open a PoS session and add the product with an extra price
attribute to the order
7. Add a line discount to the order line and validate the order
-> The discount amount is based on the listing price of the product
opw-3297713
closesodoo/odoo#131606
X-original-commit: 25f293ee6f601df5b2216d419ec0215710b9fef0
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
This commit fixes an issue causing website's `systrayItems` to don't be
styled correctly.
task-3446638
part of task-3326263
closesodoo/odoo#131099
X-original-commit: 902634b5af29021e85c0232673cf5c0df0120ac3
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The sequence number, if present, was to be valitaded to match the invoice date.
However, this legimitately strict constraint would stop saving a draft invoice with an incoherent sequence number, for instance draft invoices or invoices being scanned by the OCR.
Added an extra condition deactivating the sequence check unless the action is to post the invoice.
task-3451883
closesodoo/odoo#131591
X-original-commit: 00c34755e609e2d2ad7706ead3c188266fbe529f
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce
==================
- Go to project
- Switch to the list view
- Remove some optional fields
- Click on the export all button next to the "New Button"
The optional fields configuration are ignored and all fields are
exported.
Cause of the issue
==================
The `optionalActiveFields` are not taken into account when computing the
`defaultExportList`.
This was the case in 15.0
opw-3452459
closesodoo/odoo#131594
X-original-commit: 2a397cb5bb89d1a10e7ac765ff9035c102fbb436
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
In b1e2c3453f50cc05a1b03dc1c8571a01ad7b7dd2, the `res.users.settings`
model was moved from `mail/` to `base/`, but its record rules remained
in `mail/`. This means that if `mail/` is not installed, users will be
able to access other users' `res.users.settings` records. In practice,
this is not a problem, as the only field that can exist in
`res.users.settings` without `mail/` is `homemenu_config`, which
contains nothing senstive.
This commit moves the forgotten record rules to `base/`, preventing
potential problems if new fields with sensitive information were to be
added to `res.users.settings` in the future.
Task-3461652
closesodoo/odoo#131538
X-original-commit: 5a79550c8e35ce733375c2ef7df2ea12e6added6
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Before 16.0, optional columns used local_storage service that used
JSON.stringify and JSON.parse to store values and so the object were
directly usable.
Since 16.0, we are using the localStorage API directly, so when checking
if a optional field is enabled, we just check for example:
_.contains('currency_id,partner_id', 'id')
which returns true but shouldn't => this causes for example the ID field
to not be hideable.
note: this commit makes makeRAMLocalStorage (used for safari incognito
and tests) consistent with localStorage that stores values as string.
note: the added test without the fix, fails with:
should have 3 th, 1 for selector, 1 for columns, 1 for optional
columns ever after listview reload. Expected: 3, Result: 4.
opw-3339416
closesodoo/odoo#131309
X-original-commit: 922bd446708e05c2368a01b2399855845246885b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Problem
---------
When an invoice or bill has been canceled, the Due Date for the payment
is still showing, even though this information is not relevant anymore
as no payment is expected.
Objective
---------
Make due date invisible when the invoice/bill is cancelled.
Solution
---------
Modify the invisible attrs condition of the field in the account_move
tree view by add a condition on the state.
task-3439357
closesodoo/odoo#130028
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Improve gettext to directly handle value injection within translations,
removing the need for sprintf.
closesodoo/odoo#123932
Related: odoo/enterprise#45370
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Following the rework of global ACLs here:
odoo/odoo@7dd1796eb7
Public users cannot access the event.sponsor.type model anymore.
This caused the sponsor "closing hours" modal to not be shown anymore, as it
raised an access error.
To fix the issue, we sudo the sponsor type access in the controller that
retrieves the sponsor data to render the template.
Task-3459726
closesodoo/odoo#131537
X-original-commit: 98c01e65277a816ec4010f3c6902953366d35cbc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
An error occurs when the user attempts to delete the 'database.secret' record,
either by following these steps:
- Enable developer mode.
- Go to Settings > Technical > System Parameters.
- Select the 'database.secret' record and attempt to delete it.
Or when the user tries to update the key for the 'database.secret' record using
the following steps:
- Open the 'database.secret' record.
- Update the value of the key field.
- Save the record.
- The server will stop running and not be accessible.
Error: ValueError: CSRF protection requires a configured database secret
sentry - 4291267997
closesodoo/odoo#131460
X-original-commit: fe694e5b8285ceed99b321c22af534eee25cf282
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Since 6f182eeeab,
UoM should be created through the UoM category tab as the UoM form view is now unusable.
Previous bugfix commit 58a3954d606d48b2a4cf678eb0bf13d6e28b1aef disabled
the menu from the different applications, but later changes in sale
brought back the menu again.
Since it doesn't hurt to have the menu in debug mode, the lowest solution
would be to disable the creation of uoms from the uoms tree view.
closesodoo/odoo#131237
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In this PR we fix a number of small issues related to the pos ui.
In addition to the specific fixes, this PR also simplifies many
of the components, most notably the `category_selector`.
In the interest of providing a cleaner API, this PR introduces
a new folder called `generic_components` whose goal is to contain
stateless components. These stateless components would allow for more
reusability, while simplifying the logic. The `category_selector` is
the first component in this folder.
Descriptions of each of the issues fixed in this PR can be found in the
closesodoo/odoo#131038
Tasks: 3457213
Related: odoo/enterprise#45600
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before:
When number of available domains exceeded the display limit, user was
unaware of the other available domains as nothing in UI indicated so.
Visible entries change only when user starts typing something.
After:
This commit adds a 'Start typing...' entry after visible models in
dropdown menu whenever number of available models exceed the display limit,
in order to provide a hint to the user.
When user starts typing, 'Start typing...' entry disappears and all available
domains are displayed with a scrollbar.
Task ID : 3375332
closesodoo/odoo#126156
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
RATIONALE
This prepares the move of ICP to mail before replacing them by dynamic alias
domains.
Cleanup tests: try to use loops with input / expected to better understand
the various test cases, add some comments, improve logs when failing to
find the right sent email. Rename tests to have a better test structure
when reading logs.
Remove a test from odoo/odoo@3b6c20805c that adds nothing except testing
the test suite.
OTHER ADDONS
In test_mail: have a specific class for testing servers as other data is
not necessary, and it allows to have a tag for it.
In mass mailing: concatenate test about server finding, several tests can be
done in a single unit test.
Task-3453577 (TestMail: Update Alias/Gateway tests for MC)
Prepares Task-3453347 (Mail: Move Mail ICP from Base to Mail)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#131492
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit there are no rollback if raise.
closesodoo/odoo#131490
X-original-commit: 0015662d166f5e07bcbd6c5e9e14f8837ffa58a3
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Touati Djamel (otd)