During a return the purchase_order_line field is propagate, order_line.move_ids include returned move, that why use returned_move_ids is not mandatory.
closesodoo/odoo#35878
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
For this case, if the invoice currency is different from the invoice company currency, the tax calculation is considered the value in a different currency, and the subtotal is the sum of the amount untaxed + the taxes (wrongly in company currency) result in an incorrect value. This is verified when printing the invoice report
closesodoo/odoo#62388
X-original-commit: 91f152f479923a1d28dadcb3ded7c0296cc585fc
Signed-off-by: Josse Colpaert <jco@openerp.com>
Before this commit the navigation toolbar was accessible after selecting
a theme before the editor was opened, which on slow connections made it
possible for users to leave the screen and miss the tour
After this commit the loader animation of the theme installation is
blocking the access to the screen until the editor is opened thus
preventing user to navigate elsewhere before seeing the tour
task-2387608
closesodoo/odoo#62029
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit makes it so the quantity of a SN in a location is now
restricted between -1 < quantity < 1 (previously it was only quantity <
1). This change provides stronger protection against a duplicated SN
(e.g. a quantity of -2 means that the SN was somehow moved from that
location twice). This restriction was also relaxed to not include
location.usage='inventory' because this could prevent the user from
fixing a duplicated SN (since they were prevented from creating a
quantity of 2+ in an Inventory Loss location).
closesodoo/odoo#59834
Task: 2336455
Related: odoo/upgrade#1839
Related: odoo/enterprise#14667
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Add a new feature to automatically create/update/delete an inventory by
company for products with conflicting serial numbers. The goal
of this is to help track inventory discrepencies and prevent duplicate
serial numbers across different locations.
This follows the same logic as the negative qty count auto-inventory
feature where a dupe SN inventory will be auto-generated / auto-updated
/ auto-deleted when the "Inventory Adjustment" button is pushed and when
the scheduler is run. Note that -1 quantity of an already in use SN
counts as a duplication of a SN.
Note: a new many2many field `lot_ids` was added to inventory to more
easily track which conflicting SNs to do the inventory on.
Task: 2336455
ENT PR: odoo/enterprise#14667
Upgrade PR: odoo/upgrade#1839
Add a new feature to automatically create/update an inventory per
warehouse specific to products with negative qty in any of its
locations. The goal of this is to help track inventory discrepencies
and prevent appearance of being out of stock when there is still stock
left. This is done by having the inventories update/create whenever
the "Inventory Adjustments" menuitem is clicked. Since we don't know
when a product's stock becomes non-negative, we always re-write all the
neg products to existing draft neg inventories and remove any
pre-existing draft inventories that haven't been updated since they no
longer have any neg qty products anymore.
Scheduler will also trigger this recalculation in hopes that it will
reduce having a large number of inventories to create when the inventory
menuitem isn't opened very often.
Note: a flag `is_conflict_inventory` was added to avoid conflicts with
manually generated inventories.
Task: 2336455
ENT PR: odoo/enterprise#14667
Upgrade PR: odoo/upgrade#1839
Add a new feature to allow automated (as part of scheduler) generation
of inventory adjustments based on user set value for how often they should
be done for 'internal' and 'transit' locations.
- When is the inventory created?
When cyclic frequency is set to a non-zero value, the next date an
inventory should be automatically generated for a location is based on
whether or not a previous inventory for that location was completed.
If an inventory is overdue based on the previous inventory date, one
will be scheduled for tomorrow. If no previous inventory date exists,
schedule the next one based on today's date. A new inventory will be
created by the scheduler if there is not an existing in progress
inventory for the location (to avoid a conflict).
- What about descendant locations?
Descendent locations will not have an inventory created if their
ancestor is supposed to have a cyclic inventory done at the same time.
Note this includes when that ancestory already has an in progress
inventory and isn't having a new one created.
- What about cleaning out of date cyclic inventories?
This automation will also delete existing draft inventories that include
this location (created before the day the scheduler is run) or any of
its descendants (i.e. inventories with only that descendant location
selected to avoid deleting obviously manually created inventories).
Task: 2336455
Upgrade PR: odoo/upgrade#1839
Prior to 28762b79e3, `_enableButtons`
method is mainly called after saving changes in the record,
now, it is also called when discarding such that its argument can
become `undefined`. This causes error in pos.config form because it
uses a custom form which hooked to the said method in order to
reload the window when a module_ or group_ field is modified.
This commit prevents this error by having a fallback empty array
when `changedFields` is `undefined`.
closesodoo/odoo#62366
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider a product P with purchase UOM = Unit
- Let's consider a UOM called Box such as 1 Box = Units
- P is invoiced according to its ordered quantity
- Create a PO for 1 Box of P and confirm it
- Create the bill B from PO
Bug:
The quantity of B was 10 and its UOM was Box
PS: When creating a bill from a PO, by default the quantities on the lines of B are always expected
in the UOM of their respective PO line
Introduced by: https://github.com/odoo/odoo/commit/d0455ae64ba3800c8a13c60c6b68a5638ed5d552
opw:2391243
closesodoo/odoo#62356
X-original-commit: 669d1ee563ad123a1db417306191c670ea741925
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Since commit https://github.com/odoo/odoo/commit/3ad4abe171e8e7e86ed0e7b7f000e734d8a2ad92
the default invoicing policy of a product is set to 'delivery'. This is
not ok for the delivery products: a delivery product is never delivered.
This is confusing to end users, because they do not realize that a
delivery line is not included in an invoice. This is especially true if
the delivery is free.
This commit sets the default policy to 'order' for master data and for
newly created products from the shipping form view.
opw-2387437
closesodoo/odoo#62357
X-original-commit: 4c2768846809f6687d03eb0d7f501e57c2c93a90
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
On a mobile, when editing a transfer operation, it is not possible to create a new lot/serial number.
To reproduce the error:
(Need a single company configuration)
1. Inventory > Configuration > Settings
2. Enable "Lots & Serial Numbers"
3. Inventory > Products > Products
4. Create a new one
- Set "Tracking" to "By Lots"
5. Operations > Transfers
6. Create a new one
- Add the product and set a demand
7. Save & Mark as todo
8. Enable the mobile mode of your browser & Refresh the page
9. Edit the transfer
10. On the product line previously added, click on details (to set the quantitiy done)
11. Click on "Add"
12. Click on "Lot/Serial Number" field
13. Create
14. Save
=> Validation Error (field Company is missing)
OPW-2389965
closesodoo/odoo#62301
X-original-commit: 6f0c3e9b23d785d5348817d9a23e34f7d4c1f835
Signed-off-by: adwid <adwid@users.noreply.github.com>
What are the steps to reproduce your issue ?
1. Install 'Manufacture' and enable 'Work Order' in settings
2. Create product 'ProductA', enable 'Manufacture' in 'Inventory' tab
3. Create a BOM for 'ProductA'
4. For that BOM, create a new operation called 'OperationA' with PDF worksheet but don't attach any PDF
4. Go to 'Manufacture' and create a MO with 'ProductA', the 'OperationA' is automatically set in 'Work Orders'
5. Start the work order
What is currently happening ?
When you try to pause, an error is raised.
'TypeError: Cannot read property 'pdfViewer' of undefined'
What are you expecting to happen ?
Start and pause the work order even without attached PDF.
Why is this happening ?
'this.pdfViewer = existing.data('PDFViewerApplication').pdfViewer'
When there is no pdf attached. The data 'PDFViewerApplication' does not exist.
How to fix the bug ?
Change worksheet default value to text, and make the field mandatory in case of a PDF type
opw-2387428
closesodoo/odoo#62350
X-original-commit: 8597aada3d9bacc3cff4707bb78a7bc48d723cfb
Related: odoo/enterprise#14992
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Blocks and Rainy / Airy and Zigs merged together
Fix color of Bold 5 and bold 6 shape that are not easy to use due to contrast
with black, now it is grey by default.
task-2357174
closesodoo/odoo#62352
X-original-commit: 978fcbd4f6ba9f618b69560cb5fbe26602828bcb
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit Bold shape 10 & 11 had no transparent color
After this commit Bold shape 10 & 11 have a transparent color instead of
their former color #3 (#F6F6F6)
task-2357174
https://github.com/odoo/odoo/pull/59613
X-original-commit: 71b3b2d61b7acad601da38457671a20357298587
Before this commit, it was impossible to write to a delegated m2o field
if the length of the recordset was greater than 1.
The reason was because the special case for delegated fields inside
fields.Many2one.convert_to_cache would check for `record.id` which is a
bit misleading, since record can be greater than one.
The solution is to check whether any of the records are real records
instead, as if all of the records are NewRecords, then the parent is a
NewRecord too.
Fixes#62069closesodoo/odoo#62343
X-original-commit: 76bf9dc94165c79be873a8864bfdb50a0a636084
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before, on request by groups, now we use a variable is_system / is_designer
to make only once the request.
closesodoo/odoo#62313
Related: odoo/enterprise#14970
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Purpose
=======
The goal of this contraint is to prevent employees to take a time off
when he's not supposed to work (example: after the end of his contract).
But, in some conditions (example: we change the contract end date), the
number_of_days is not recomputed, and the constraint is raised
when unlinking the time off.
Move the chunk of code at the validation level, to prevent validating
a time off if the employee is not supposed to work.
closesodoo/odoo#62337
X-original-commit: c0e082ee1fba7cecc711f724974d79ed65bab29b
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
It's possible to create a new activity when editing a existing activity (done
and schedule next). In this case, we must refresh the activity list, otherwise
they wont be in the chatter.
task-2389961
closesodoo/odoo#62333
X-original-commit: 26a2c047a2757c600b3128fe753fa1328043a245
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
Remove unused blank templates in crm and mail.
SPECIFICATIONS: TEMPLATES MOVE
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
SPECIFICATIONS: REMOVE BLANK TEMPLATES
Crm and mail hold a blank template that adds no real value. Its purpose was to
give a base for salesmen to perform a mass mailing on leads. Using a template
and its action menu entry it was possible to launch a mail composer in
mass mail mode on leads.
However template itself is not necessary. Same goal can be achieved with
a standard action. As template was blank and creating noise we can remove
it and simplify available templates.
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Mail holds a blank template that adds no real value. Its purpose was to
give a base for parner managers to perform a mass mailing on leads. Using a
template and its action menu entry it was possible to launch a mail composer
in mass mail mode on leads.
However template itself is not necessary. Same goal can be achieved with
a standard action. As template was blank and creating noise we can remove
it and simplify available templates.
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
Crm holds a blank template that adds no real value. Its purpose was to
give a base for salesmen to perform a mass mailing on leads. Using a template
and its action menu entry it was possible to launch a mail composer in
mass mail mode on leads.
However template itself is not necessary. Same goal can be achieved with
a standard action. As template was blank and creating noise we can remove
it and simplify available templates.
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#19366
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#19366
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
Instances like deleting a tax used in a pos.order before closing a
session is allowed but it renders error when closing the session
because of imbalance move lines. In this commit, we are adding
a 'balancing' line in the move before it is created. This ensures
the closing of pos session. The introduced move line is named
'Difference at closing PoS session' and is a receivable making it
easy to find and can be reconciled.
closesodoo/odoo#62308
X-original-commit: 7b9545387962981b5729318e2bbc5714dcbac68c
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
A based on rules shipping method with the "Free if order amount is above" field enabled is not correctly applied.
To reproduce the error:
(Need website_sale)
1. Go to Settings > Website
2. Enable "Shipping Costs"
3. Go to Website > Configuration > eCommerce > Shipping Methods
4. Create a new one
- Select "Based on Rules"
- Enable "Free if order amount is above"
- Set the corresponding amount
- In pricing, add a line
5. Save & Publish (Click on "Unpublished")
6. Go to website's shop
7. Add the product set in the shipping method to your cart
- Select an amount sufficient to exceed the threshold amount set in step 4
8. Process Checkout
=> The shipping method is shown, but the associated amount is "No price rule matching this order[...]"
The shipping method price should be 0.
(This error also happens when creating a SO)
OPW-2383258
closesodoo/odoo#62290
X-original-commit: 393b7ad7b7dff1cbf830374c76ef0a681a71be6a
Signed-off-by: adwid <adwid@users.noreply.github.com>
Same change in several areas where translations existed:
- website editor notification popup
- elearning share popup
- forum remediation filter popup
- event registration attendees popup
- portal rating popup
- stripe payment error popup
And many other locations where there were no translations yet
"×" has been replaced by its UTF8 character.
Also introduced aria-label where missing.
Before this commit the close icon was included in translated resources.
For example, in Spanish the "×" had been turned into "&veces;"
thus not rendering an icon anymore
After this commit the close icon is not a translated text anymore and
remains an icon across all languages
https://github.com/odoo/odoo/pull/60186
task-2312878
closesodoo/odoo#62250
X-original-commit: 9896af94ebc887d98ccf44e6568ef7eeb5a27172
Related: odoo/enterprise#14937
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
One can set a Unit of Measure precision rounding more
precise than the overall Decimal Accuracy. This can trigger the error
'It is not possible to unreserve more products', as there will be
inconsistencies on reserved quantities due to decimal roundings.
We add 2 warnings on Units of Measure and Decimal Accuracy.
Therefore, users are warned when their UOM/decimal changes can
cause inconsistencies in quants reservation.
Also, we want to prevent the issue at the root by ensuring that both the move
and the quant have the same reserved quantity.
The contrary can happen e.g. when a product is defined in Liters (rounding .001)
but used in an operation in ml (rounding .01, so e.g. 187.5ml).
The conversions between the 2 UOM can cause the differences of reservations.
In _prepare_move_line_vals we make sure uom_quantity_back_to_product_uom
is not more precise than the overall Decimal Accuracy. That way, if
the reserved quantity changes between UOM conversions, the move line created
is in the quant/product UOM, and we do not have move line's reserved quantity >
quantity in stock.
We do the same for _update_reserved_quantity (stock.move), when updating
a move line.
In _update_move_lines, because of UOM conversions, new_quantity_done
can differ from ml.product_uom_qty, which triggers the creation of an extra
move line, leading to reserved quantity > quantity in stock. To prevent
that, we compare the reserved quantities in the product UOM.
opw 2206902 (Example 1)
opw 2171541
opw 2221227
opw 2233937
opw 2198775
and many more
closesodoo/odoo#62279
X-original-commit: 478a42beb5876171afeab7df27fa69548edbf849
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When modifying a field's decimal precision, the caches are cleared in
order to retrieve the new value from the database. As the new value is
retrieved in pure SQL, one has to flush the updates before doing the
query!
X-original-commit: 8a9617d045c2afda8d804a5863df927012f0692c
Steps to reproduce the bug:
- Let's consider a configuration with two languages L1 and L2
- Go to Settings / Accounting / Customer Invoice / Default term & condition
- Define a default text T1 and save
- Create a new customer invoice, T1 is displayed in the field narration
- Go to Settings / Accounting / Customer Invoice / Default term & condition
- Change T1 to T2 for L1, L2 and save
- Create a new customer invoice
Bug:
T2 was displayed in the field narration
opw:2388353
closesodoo/odoo#62270
X-original-commit: 98d36b80ed1b4f11491301d3b7b5818d81edf542
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Purpose is notably to display last survey attempt as "Date of certification"
instead of first one. We therefore set an _order on survey.user_input model
(user participation to a survey) as create_date desc. When several attempts
are made the last one will be considered when doing a search with limit=1.
Closes#61362
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Stefano Consolaro