As rewrite the whole chart template mechanism,
From here: https://github.com/odoo/odoo/commit/512574861691f425ec6a17f20fe4b586bb88a299
we need to remove chart template reference from
localization module. some of them are remaining.
so removed from Turkey, Turkey localization in migration
script otherwise we got this error:
```
File "/home/odoo/src/odoo/saas-16.3/addons/l10n_tr/migrations/1.1/end-migrate_update_taxes.py", line 2, in <module>
from odoo.addons.account.models.chart_template import update_taxes_from_templates
ImportError: cannot import name 'update_taxes_from_templates' from 'odoo.addons.account.models.chart_template'
(/home/odoo/src/odoo/saas-16.3/addons/account/models/chart_template.py)
```
closesodoo/odoo#133463
X-original-commit: 57a32afb534f18022d632b03a39a316bce2817ab
Signed-off-by: William André (wan) <wan@odoo.com>
Purpose:
-
The `useSortableList` hook introduced to replace the usage of the jquery library "nestedSortable" in knowledge's sidebar is moved to web so that it can be used in documents to allow the reordering of folders in the search panel (see the [related enterprise PR](https://github.com/odoo/enterprise/pull/45729))
Some tests have been added, as well as small fixes in the hook that were pointed out by adding these tests, notably:
- the moves are now triggered based on the position of the top of the dragged element instead of the position of the cursor (behavior was unclear when moving long elements)
- when nesting is allowed, moving an element under another one that does not have nested elements now inserts the placeholder after the element instead of nesting it inside of it.
Task-3422012
closesodoo/odoo#131769
Related: odoo/enterprise#45729
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Purpose:
--------
This commit adds QUnit tests for the `useNestedSortable` hook.
This commit also fixes a few issues in the hook that were pointed out by
adding these tests, notably:
- the moves are now triggered based on the position of the top of the
dragged element instead of the position of the cursor (behavior was
unclear when moving long elements)
- when nesting is allowed, moving an element under another one that does
not have nested elements now inserts the placeholder after the element
instead of nesting it inside of it.
It also renames the `listType` parameter to `listTagName` to make its
purpose clearer, and moves the placeholder styling to a custom class so
that it can be customized more easily.
Task-3422012
Part-of: odoo/odoo#131769
Purpose:
--------
The `useSortableList` hook introduced to replace the usage of the jquery
library nestedSortable in knowledge sidebar is suitable for the sidebar
in documents, which currently does not allow to move a folder between
other folders.
The hook is moved to web so that it can be used in both modules
Task-3422012
Part-of: odoo/odoo#131769
- Updates the product.product kanban view so that it matches
the product.template one.
- Fixes the favorite button
- hr_expense also requires the cost to be shown
task-3457035
closesodoo/odoo#131208
Signed-off-by: William André (wan) <wan@odoo.com>
When user delete product in 'hr_expense' module that is present in the demo data
of 'sale_expense'. While installing 'sale_expense' module the user is getting
error as the product that is referenced from 'hr_expense' has been deleted.
Steps to produce:
- Install hr_expense module.
- Delete all expenses.
- Go to configuration and then Expense Categories.
- Delete any category between 'Meals', 'Mileage', 'Travel & Accommodation' and
'Communication'.
- Install 'sale_expense' module.
Traceback will be generated.
Applying this changes will resolve this issue.
sentry-4113713209
closesodoo/odoo#121752
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, when a regular barcode, like '3700000000370', which
could be interpreted using GS1 rules, was scanned in PoS, it was
incorrectly identified as a GS1 barcode even though it didn't contain
a product reference. This commit addresses this issue by implementing
a validation check during barcode scanning. The system now verifies
whether a scanned barcode conforms to GS1 rules and contains a product
reference. This ensures accurate barcode recognition.
opw-3468158
closesodoo/odoo#134069
X-original-commit: a62a9ef5f3a0067ed5eb772f850f6ef0fefb6821
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Prior to this commit, when limited product loading was enabled,
scanning a product that had not been loaded yet would trigger a search
for the product without taking into account the available_in_pos field,
and it would also set available_in_pos to true.
This commit ensures that when a product is loaded using its barcode,
the behavior aligns with the changes introduced in this
commit: https://github.com/odoo/odoo/pull/87329/commits/a83c7aea37b06e8b1f04f1f02982ff577d7058e9
opw-3463427
closesodoo/odoo#134038
X-original-commit: 4fee329af13d9335f743aae39ff1a4b6ad4ee0f5
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Iusse:
======
When you update a chatbot a line and then save the chatbot form it will
throw an error.
Steps to reproduce the error:
=============================
1-Go to Live Chat/configuration/Chatbots and select one
2-update one line in the script (add some letters in one name)
3-save the chatbot form
Problem:
========
Some fieldName doesn't exist in the list of fields.
Solution:
=========
Swapped the values in the assign in duplicateDataPoint.
opw-3454514
closesodoo/odoo#134024
X-original-commit: 4ce57085b302957e2c260183f05f534160fa7ea4
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
**Changelog**
**3.4.2 (2023-08-26)**
- Fixes regression from 3.4.1 (moment/luxon#1493)
**3.4.1 (2023-08-23)**
- Fixes for regressions from 3.4.0
(moment/luxon#1482 and moment/luxon#1488)
**3.4.0 (2023-08-08)**
- Fix type checking on input zones
- Fix Islamic months listing
- Fix normalize() for negative inputs
**3.3.0 (2023-03-03)**
- Fix off-by-one in Interval#count (moment/luxon#1308)
- Support formatting for custom zones (moment/luxon#1377)
- Fix parsing for narrow spaces (moment/luxon#1369)
- Handle leap year issue with AD 100 (moment/luxon#1390)
- Allow parsing of just an offset
**3.2.1 (2023-01-04)**
- Fix for RFC-2822 regex vulnerability
- Better handling of BCP tags with -x- extensions
**3.2.0 (2022-12-29)**
- Allow timeZone to be specified as an intl option
- Fix for diff's handling of end-of-month when crossing leap years
(moment/luxon#1340)
- Add Interval.toLocaleString() (moment/luxon#1320)
**3.1.1 (2022-11-28)**
- Add Settings.twoDigitCutoffYear
**3.1.0 (2022-10-31)**
- Add Duration.rescale
**3.0.4 (2022-09-24)**
- Fix quarters in diffs (moment/luxon#1279)
- Export package.json in package (moment/luxon#1239)
**3.0.2 (2022-08-28)**
- Lots of doc changes
- Added DateTime.expandFormat
- Added support for custom conversion matrices in Durations
closesodoo/odoo#133599
Related: odoo/enterprise#46556
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Steps:
No precise steps:
Send/Receive a email in discuss
Reply to it via email
Actual result: crash
Expected result: no crash
opw-3480185
closesodoo/odoo#133370
X-original-commit: 298be6b3762d24883f5019e094425ab8fbdd95e0
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
As tempusdominus relies on jQuery, we have written our own date(time)
picker in owl. This commit converts the remaining uses of the
tempusdominus date(time) picker and replaces them by our own.
closesodoo/odoo#133349
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
This commit improves the support for time in the datetime picker by
doing two things:
- allow to pick seconds by giving a rounding value of 0
- check minDate and maxDate by accounting for the time when the picker
is in datetime mode instead of only checking the date
Part-of: odoo/odoo#133349
This commit, adds a new python method (`web_save`) to save a record, and
optionally read-it again in one rpc call. This optimizes the current
behavior that is to save a record in one rpc, and read-it in a second
rpc.
web_save, will receive the list of IDs of the records to save (if this
list is empty it will create the records, if not, it will write on the
existing records), the list of changed fields, and the unity
specification as optional argument to read the created/modified records
(if the specification is not set, the function will return a list of IDs
of the created/modified records).
closesodoo/odoo#133021
Task-id: 3453184
Related: odoo/enterprise#46559
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When _create() is invoked, it inserts rows into the database, and sets
the cache of the corresponding records to the values that are inserted.
If a field is not passed to _create(), we assume that its database value
will be NULL (or falsy, at least) and put None in cache, in order to
avoid fetching that value. However, this only makes sense for stored
fields.
Part-of: odoo/odoo#133021
Usecase:
- Create a BoM for a template
- Replenish 2 different variant
Expected result:
2 distinct production orders for each product
Current result:
A signle production order with the first product variant and twice the
quantity
closesodoo/odoo#134067
X-original-commit: 2a658fb4a509238cd1462e2ffb615ecec05bc2e2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Since [1] images uploaded through the website builder that are neither
GIF nor SVG are converted to the WEBP format by default.
The upload of product extra images does not follow this rule.
Adding the extra images is done through its own specific route instead
of putting the images inside the DOM before the save, it therefore does
not run though the general image tools code.
This commit converts the uploaded product extra images to WEBP before
saving them into the records.
It is achieved by following the same approach as when uploading a WEBP
in the backend [2], before calling the `/shop/product/extra-images` RPC.
The fix is not done by replacing the custom route by an update of the
DOM with the images because a full page rendering from the server is
needed when adding extra images.
Steps to reproduce:
- Edit a product through the website builder
- Add a JPG extra image
- Save the page to leave the website builder
- Check the image content
=> Image was a JPG instead of WEBP.
[1]: https://github.com/odoo/odoo/commit/0449fe85cb0e1d639a4e1aeba26e90906f79254d
[2]: https://github.com/odoo/odoo/commit/40955397658e4bf858e969668079d0c6a4cef43b
task-3460171
closesodoo/odoo#134037
X-original-commit: f970147a2113608d18b47c6f59de6c6338bb2f43
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Reload button appeared when no chart_template was set which
could make Odoo delete important data if clicked.
We restrict appearance of the reload button to avoid this situation.
Also adds a short description on the button to notify user of the
irreversability of the action.
Steps to reproduce:
1. Create a company (do not use the default one that has Generic CoA set) with a country set.
2. Create accounts : income, receivable and payable.
3. Create a sale journal with the income account.
4. Go to a partner detail (e.g. Deco addict), tab Accounting and set its receivable/payable accounts to the ones created above.
5. Create an invoice for that partner.
6. Go in Accounting Settings and click the reload button.
=> The invoice is deleted.
Task-3488427
OPW-3448881
closesodoo/odoo#134028
X-original-commit: a636b9386f297f9f08a38689911ca111fe597ec3
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
This traceback raises when user changes the product type to 'consumable' in a
sale order and clicks the 'recorded' stat button.
To reproduce this issue:
1) Install 'sale_timesheet'
2) Create a new 'sale order'
3) Select any customer > Select a product with the 'service' type.
4) Click Confirm, then proceed to click the Create Project button.
5) Give any name to the project > Return to that sale order.
6) Now a 'recorded' stat button is visible > Click on that and create a record.
7) Return to that sale order > Go to the order lines, and for the previously
selected product, change the product type to 'consumable'
8) Once again, go to that 'sale order' and click on the 'recorded' stat button.
Error: "StopIteration: null"
[1] On the 'action_view_timesheet' method 'default_sale_line' variable is
getting a record with a condition of 'sale.order.line' is_service must be true
and 'service_policy' in 'order_prepaid' or 'delivered_timesheet' .
[2] But 'is_service' is getting value through a compute method in which
product type is equal to 'service'.
Because the user changed the type to 'consumable', the iteration ends with no
records and there is no default value. So it leads to the above traceback.
[1]
https://github.com/odoo/odoo/blob/69fca30bb4fb66e6d979ce5ddc1bff4db963ca71/addons/sale_timesheet/models/sale_order.py#L105-L111
[2]
https://github.com/odoo/odoo/blob/69fca30bb4fb66e6d979ce5ddc1bff4db963ca71/addons/sale_service/models/sale_order_line.py#L18-L20
sentry-4396433586
closesodoo/odoo#133903
X-original-commit: 062cec2175e5b22126b5c3be5acef5039ca1e804
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
There are cases where the result of `check_company_domain_parent_of`
is used in in a loop, leading to the parent_of relation being
recomputed once or even multiple times per iteration during SQL
evaluation.
Computing the parent relationship turns out to be fairly expensive in
worst case scenarios (e.g. lots of companies), so while precomputing
doesn't save much for a 1:1 situation (though it does make the job of
the expressions compiler a bit simpler), the ability to compute it
just once instead of say 140 times does make a huge difference in
e.g. some report renderings.
Nota: apparently `_check_company_domain` can be called with a string
because lol, so there's a special case for that.
closesodoo/odoo#133530
X-original-commit: 2f9ae135c9dd7cb09fa83fda7a9b304993cb3edc
Related: odoo/enterprise#46518
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Account codes are very commonly searched by prefix. This field used to
be implicitly indexed thanks to a unique constraint on `(code,
company_id)`, however the constraint was removed in #125642 rather
than converted to an index.
For the issue at hand `code` has a much higher discrimination power
than `company_id`, however it might make sense to also index
`company_id`, or to add compound indexes for `code, company_id` and /
or `company_id, code` for other work loads.
X-original-commit: 45c579908d90f6275b7d255d59c6555e8a57b959
Part-of: odoo/odoo#133530
*: pos_discount,pos_loyalty,pos_restaurant,pos_self_order
In a previous commit (669b9fcc2f) we added the
backend logic needed for creating combos in `pos`.
In this PR we add the combo functionality to the classic pos ui.
This means that products can now be grouped together and sold as a combo.
ex: Create a product called `Burger Menu` with type='combo'.This product will
have multiple combos associated with it, for ex:
- Drinks - will contain the list of drinks from which the customer can choose
- Main Course - will contain the list of main courses from which the customer
can choose
- Dessert - will contain the list of desserts from which the customer can choose
In the event that one of the products inside one of the combos is to be more
expensive, this product will have a specific `combo_price` which will be added
to the main combo product's price.
We add the relational fields `combo_parent_id` and `combo_line_ids` in the
`pos.order.line` model. In the previous example, `combo_parent_id` will contain
the `id` of the `orderline` of the `Burger Menu` product.
In many cases `combo lines` have to be handled together. For example, deletion
of an orderline containing a product from a combo implies the deletion of all
other orderlines containing products from that combo. This means that multiple
methods from the codebase had to be changed for this reason. Places that needed
changes for this reason:
- `split_bill_screen.js`
- `addProductToCurrentOrder()`
- `remove_orderline()` and `add_orderline()` from the `Order` js model
In this PR we also:
- improve the demo data such that it contains a `pos combo`;
- refactor the `ProductItem` component such that it relies on a stateless
component. This stateless component can now be used anywhere; ( it is now used
in the popup which allows selecting the desired combo products )
- add a new method called `is_pos_groupable` on the `Orderline` js model. Before
we relied on the product unit to see whether or not a product is groupable. We
now needed a new mechanism, which could account for different reasons for
which products are not groupable, such as belonging in a combo;
Note on price calculation:
- The idea is simple, imagine a rectangle divided into two parts. The whole
rectangle is the total order, whereas the two partitions are the orderlines.
- Now, imagine shrinking the rectangle by a certain factor. This shrinked
rectangle represents an order containing a combo -- because normally, a
combo results to smaller price. The two partitions are also shrinked by the
same factor.
- So the calculation will be:
- Nominal total price is calculated. This is the sum of the orderlines'
prices when they are added individually. This represents the whole
rectangle.
- Target price is derived from the combo product's price and selected
components' combo prices. This represents the shrinked rectangle.
- Reduction factor is computed as the ratio between the target price and the
nominal price.
- Each component's unit price is adjusted by multiplying the reduction
factor.
- When the unit prices of the components are computed, we now let the normal
price computation take place.
- A spreadsheet is prepared to show a sample calculation:
https://docs.google.com/spreadsheets/d/1iOdnaILnvKiaf2_z7jTijYiVfB_3mjKWjq6nOB70Un0/edit#gid=0closesodoo/odoo#129483
Task: 3430636
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Co-authored-by: Joseph Caburnay <jcb@odoo.com>
Changes in default can be bothersome, embed a full baseline
configuration for reliability.
closesodoo/odoo#27926
Signed-off-by: Pierre Masereel <pim@odoo.com>
Before this commit when we login as a user having project rights and open the
form view then 'project status' stat button isn't clickable. So in this commit
we have fixed that issue by giving group project user groups to stat button .
task-3432384
closesodoo/odoo#133927
X-original-commit: 0672824fb21e0a15dc951c46e317cb8cfc162ef2
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Dhrumil Shah (dhrs) <dhrs@odoo.com>
before this commit, from list view users can install
module using the button in list view and from the
action button.
initially the Install button was not available in the
list view and only option to install multiple apps was
from the action button.
but with the introduction of the button in list header
there is no need for an another server action to
perform the same.
after this commit, the activate modules server action
will be removed from the code and its related test
and also newly added Install button will be renamed
to "Activate" to align with the button in kanban and
form.
closesodoo/odoo#133544
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The commit f5ce6c5979e5fba1ccb7e30c8125cd7b97534925 introduced a regression that prevents closing
a POS session if the user does not have accounting and inventory
access rights.
opw-3487462
closesodoo/odoo#134055
X-original-commit: 6f43bc1972ac60e9365b40f53ee8966270e78848
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Bug:
When printing DDT documents for a delivery with a pricelist applied, the
total value shown comes from the product's original price and not the
modified pricelist price.
Setup:
- install `sale_management` and `l10n_it_stock_ddt`
- have a product P with a price A
- create a pricelist that where P has a price B
Steps to reproduce:
- activate DDT report printing
- create a quotation set the pricelist you created and the product P
- validate the quotation
- go to the associated delivery and validate it
- print the DDT report
You should see that the price mentioned on the DDT report does not
account for the pricelist. (price A is shown, instead of B)
opw-3171295
closesodoo/odoo#134017
X-original-commit: 9bdb0ed25dcef3f651a65abf0c4a8d9ce4e27851
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
When a user pays a donation with an empty amount value, the system
passes this value as an empty string, which is leading to a type-casting error
because an empty string cannot be directly converted to a numerical value like
a float.
Error: `ValueError: could not convert string to float: `
To handle this situation, we should use '_cast_as_int' and
'_cast_as_float' methods because these methods provide try-except blocks,
effectively handling these types of errors. This ensures that when an empty
amount value is encountered, the system manages the error.
sentry-4376573159
closesodoo/odoo#134026
X-original-commit: cae9f647b9e032aedfccc528d124acc639ecbf7f
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In dashboard configuration, when you click on file of 'Data' section in
debug mode to edit, icons were duplicated.
This commit fixes the issue by getting rid of the same icons in
overridden template `web.ListBinaryField` from `binary_field.xml`
in order to remove icon duplicacy.
Additionaly, this commit removes unnecessary `<i>` tags and alters the
classes of `<button>` tags instead, to maintain the visual appearance
of icons (now they look the same as everywhere else).
Task ID : 3453198
closesodoo/odoo#134005
X-original-commit: 850e16cc415486507d1984ea08a04140ffba7c61
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
When sending a mailing we make sure to preserve comments (in particular
so that MSO comments can be read by Outlook). However this was not the
case when testing a mailing using the Test button in the form view.
task-3488162
opw-3290548
opw-3479234
closesodoo/odoo#133998
X-original-commit: 66b1dc38ced221d63f11827a217f9805827d5e65
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Current behavior:
The currency used to create the report is the one of the company. But
if you use a different currency in the pos config, the report will still
be in the company currency.
To fix that we check if all report's config use the same currency and
use it if it's the case we use the pos config currency. And if it's not
possible we use the company currency.
Steps to reproduce:
- Create a second pos
- Change the sale journal and the pricelist to use a different currency
- Open a session and make a sale
- Close the session
- Generate the daily report for the second pos
- The currency is the one of the company
opw-3463280
closesodoo/odoo#133996
X-original-commit: 3af535d9008c4d839ede2b5117230fa4a19b538a
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Issue:
------
When adding a file to an employee's work permit ("Private Information tab"),
the file name is the "value" of the file.
This is not meaningful for the user who will download the file.
Solution:
---------
Use the `filename` attribute to determine the field of `hr.employee`
to be used to get the file name.
As the original file name doesn't exist in an existing field,
we can use a "generic" file name with a non-stored computed field.
opw-3458842
closesodoo/odoo#133981
X-original-commit: 2f49ec86fcd8191f92153069ae242c329a5cdf0c
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
I missed a critical issue in #133708: various users had discovered
they could already fix description issues by adding an XML declaration
to their document which is very cool (though technically not really
valid).
What is a lot less cool is that lxml gets *extremely* unhappy when
asked to parse *strings* with an encoding declaration, raising a
ValueError, so the purported fix breaks on any module which does that,
which seems to include a lot of OCA modules.
Gate the encoding guessing by bailing if the document has an XML
declaration, in which case we just assume the author knows what
they're doing and we leave them alone. For extra safety, check the
encoding declaration in ascii and utf16. Could also have checked for
BOMs, but lxml seems to not care about them overly much (in fact it
seems to prefer them decoded which is odd).
Also same as non-utf8 descriptions, mark XML declarations as
deprecated (because it's a hack to make UTF8 descriptions work which
is not necessary anymore).
closesodoo/odoo#133968
Reported-by: @rezak400
X-original-commit: fd353d7d0104431208b91603431e41ef4a6e54bb
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The purpose of this commit is to make fieldDependencies are readonly by default.
This avoids making fields unintentionally editable. If the field is editable,
it will be sent during create/write, which is what we want to avoid.
Use case:
Go to a form view with 2 fields "a" which is readonly and "b" which has
"a" as fieldDependencies.
Before this commit:
Record Datapoint thinks that field "a" is editable
After this commit:
Record Datapoint thinks that field "a" is readonly
closesodoo/odoo#132247
Related: odoo/enterprise#46691
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This traceback raises when user tries to send an invoice without attachments.
To reproduce this issue:
1) Install 'Accounting'
2) Open any existing 'Invoice'
Note:- Invoice should not be in 'Draft'
3) Click 'Send & Print ' button an wizard will be opened.
4) Click on 'Send & Print' button of wizard.
5) Now repeat the step 3
6) This time delete the Invoice Attachment and click on 'Send & Print' button
of wizard.
Error: 'A traceback appears': 'can only concatenate list (not "bool") to list'
On '_get_mail_params' method 'attachment_ids' is getting
values by concatenating 'mail_attachments_widget' and
'invoice_extra_attachments_data'.
See:-
https://github.com/odoo/odoo/blob/27c1384e1209339158f56c82bebf99a5b64811f4/addons/account/wizard/account_move_send.py#L434-L448
Because of user delete the 'Invoice attachments' in wizard, 'mail_attachments_widget'
will return false and it leads to above traceback.
Sentry-4305060652
closesodoo/odoo#133953
X-original-commit: f08da6fdfa881ec3e80d6fc14dddaa8df3c529ed
Signed-off-by: William André (wan) <wan@odoo.com>
The traceback arises when a user deletes an attachment that the referenced in
the `account.move.send` model's `mail_attachments_widget` field, and
subsequently, the cron uses `mail_attachments_widget` to send invoices.
Steps to produce:
- Install account.
- Open Invoicing > open any invoice > click on SEND & PRINT > click on SAVE.
- Add an attachment > refresh the page.
- Go to attachments > delete the attachment which you have uploaded.
- Let the cron `Send invoices automatically ` run automatically.
ERROR: Traceback will appear MissingError Record does not exist or has been
deleted.
A `mail_attachments_widget` is a `JSON`storable field (Line 1) of the
`account.move.send` model. `mail_attachments_widget` carries data like the
attachment's ID, name, and mime type. Cron utilized the
`mail_attachments_widget` field to retrieve attachment data when sending an
email with attachments. `seen_attachment_ids` is a list of IDs (Line 2) of
attachments prepared using `mail_attachments_widget`.
This commit fetches only existing attachment records from the 'ir.attachment'
model for the attachment IDs present in the `seen_attachment_ids` list.
Line [1]- https://github.com/odoo/odoo/blob/0c95e064ca6384f57154bb12d3b4ef55ee1b4da3/addons/account/wizard/account_move_send.py#L76-L80
Line [2]- https://github.com/odoo/odoo/blob/d87dc624c33c8edd0eafc130b02a95fd91e58094/addons/account/wizard/account_move_send.py#L433-L439
Sentry-4315708399
closesodoo/odoo#133951
X-original-commit: 2486300538bc68075cba530bec481909af1aeb0d
Signed-off-by: William André (wan) <wan@odoo.com>
Issue :
When you try to import a big file it will display a blank error.
Steps to reproduce the error :
1-install inventory and e-commerce
2-go to products and import records
3-upload the file attached the ticket
Reason :
Before, there was a type included in the `reason` but now
it seems that the error has no type neither a message.
Fix:
I tried to just output a general error.
opw-3410954
closesodoo/odoo#133950
X-original-commit: 95cc5c84c3b4529cd269cf278fd4ab289f28685f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Previously, if you specified a min or max date for the datetime picker
and zoomed out to the month/year/decade view, it would disable some
months/year/decade incorrectly, this was caused by the code checking if
the beginning of the period was in the min-max range instead of checking
if the period had any overlap with the min-max range.
This commit fixes that by checking for overlaps instead.
closesodoo/odoo#133911
X-original-commit: 7cb61dca99be4b0a1c35f0ec762c1bda318ec043
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Kiosk parameters were not displayed when the pos_self_order_sale module
was installed.
This was due to an overridden function in this module that didn't call
super().
This is now fixed and functional.
closesodoo/odoo#133910
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Following commit 5620e47f80
1. workcenter automatic setting should be in demo data
2. Routings in demo data where set to active=False and enable
in mrp_workorder (OE) module. Since we enable by default
workcenters in mrp, we could remove this restriction
closesodoo/odoo#133908
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit, in the kanban catalog view, when you make a groupBy
or update a record (click on the star), a crash is displayed.
Why does this happen?
The RPC for "sale_order_lines_info" is called during loadData of all dataPoint types.
Solution:
The RPC for "sale_order_lines_info" should only be called for DynamicRecordList.
closesodoo/odoo#133907
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With this commit, partner information and utm fields are pre-filled when
creating an opportunity from the many2one `opportunity_id` in `sale.order`.
Task-3442793
closesodoo/odoo#133904
X-original-commit: fb70b749e655a22ff038dff06f6317d34381d33d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Adrien Milis (miad) <miad@odoo.com>
To begin with, there are two different fields.
- tracking_number: used with the kiosk or self so that the customer can
track his order.
- name (order_reference): classic order number, used to find them in the
odoo backend.
Example of tracking number:
- A1
- B1
Example of order_reference:
- Classic PoS: Order 00001-001-0001
- SelfOrder Mobile: Self-Order 00001-001-0001
- Kiosk: Kiosk 00001-001-0001
Two ir.sequences are used to generate these numbers. The first to
generate order_reference numbers per session, and the second to generate
tracking_numbers, which are common to all pos_configs and reset once
a day.
closesodoo/odoo#133902
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
This utils also exists in /core/utils/strings and the legacy
version was no longer used. Also remove the diacritics map which
is heavy.
closesodoo/odoo#133896
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Before this commit, all python expressions in js were evaluated with
the same evalContext. Unfortunately, this is not possible for expressions
based on an x2many. The value of the x2many depends on whether the
expression will be sent to the server or not.
All expressions that are only used client-side, such as modifiers (readonly,
required, invisible), decorations, etc., must take virtual records into account.
For example, I define a button that must be visible when I have at least
one record in my x2many. So when I create my virtual record, I want
the button to become visible and not have to wait for the record to be
actually created.
For expressions sent to the server, such as domains and contexts,
we don't want them to take virtual records into account, as these are
not known by the server and could cause crashes.
Solution:
We have evalContext for expressions sent to the server
and evalContextWithVirtualIds for client-side expressions.
closesodoo/odoo#133718
Related: odoo/enterprise#46604
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Atul Patel