This commit fixes an issue with the embedded views of "My dashboard"
view: the embedded could take as much height as they needed which could
result in excessive place taken by a single embedded view and this also
had issues with the virtual hook which is not adapted to embedded views
without scroll (this could result in completly blank space inside
embedded gantt views when they would take too much space). To solve
this issue, the commit adds a fixed maximum height to the embedded views
(80% of the window height) and also adds a minimum width to their content
so that it will be horizontally scrollable instead of being weirdly
squished. Also tweaks a bit the padding of the embedded view so that it
looks a bit better even with the added scroll bars.
task-3834795
closesodoo/odoo#160568
X-original-commit: 3df65df6a4ea027b14cc7d877de96db0987f688f
Related: odoo/enterprise#60117
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Currently, a traceback appears when you attempt to generate a Facturae
document for a credit note created manually.
Steps to reproduce
------------------
* install `l10n_es_edi_facturae`
* create a credit note manually (not from an invoice)
* confirm and attempt to generate the Facturae EDI file
You should be me with a traceback:
`ValueError: not enough values to unpack (expected 1, got 0)`
Cause
-----
To generate the EDI document, the system needs the credit note to have a
link to the refunded invoice. However, in this case, there's no invoice
since the credit note was created manual.
opw-3786219
opw-3772085
closesodoo/odoo#160565
X-original-commit: 202387e518118171051e0db0fe857f44d442fb95
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Before this commit:
When disabling the submenu for events, it would show a 404
Page Not Found error.
After this commit:
the current behavior is that when the
submenu is disabled, it redirects to the /register page of the event.
task-3658380
closesodoo/odoo#160544
X-original-commit: ea140d5cfea992caad7207ff6499a46a8f575729
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Aashish Thakur (aath) <aath@odoo.com>
Currently when a time off using an overtime is written to for any
reason, it will compare the duration of the overtime with the
number_of_hours_display. However, the duration check will always be
triggered since overtime duration is number_of_hours_display * -1
This causes problems if an overtime time off is modified for any reason
and the employee does not have enough total_overtime
closesodoo/odoo#160381
X-original-commit: 1c477259d08995d1b0bfe8ebd551452073e0c03b
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
**Current behavior:**
Creating an ewallet loyalty program and removing the default
value for `trigger_product_ids` without adding another in its
place will result in any ewallet created using that program to
not have its balance deducted after being used in a sale order.
**Expected behavior:**
The default product should not be required here, nor should any
product, seeing as there is no `required` constraint on this
field nor any related ones.
**Steps to reproduce:**
1. Create an ewallet loyalty program and remove the Top-up
ewallet product
2. Create an ewallet, give it some balance, and use it in an
order
3. Check the balance of the wallet to see the erroneous behavior
**Cause of the issue:**
In the _program_check_compute_points() method of `sale.order` in
`sale_loyalty`, the conditional block:
`if not products_per_rule.get(rule):
continue`
will normally prevent rules belonging to ewallet program types
from going further in the method because they have the default
ewallet top-up product in their domain. When the continue is not
reached, they will reach this line:
`amount_paid = sum(max(0, line.price_total) for
line in order_lines if line.product_id in rule_products)`
which will end up offsetting the actual subtraction of a SOLs
`points_cost` from an ewallet `loyalty.card`'s balance.
**Fix:**
Add another check prior to the calculation of order points which
prevents ewallet coupons without any top-up products from
reaching the problematic code. If an ewallet program doesn't
have any `trigger_product_ids`, it shouldn't ever need to
perform such calculations.
opw-3756134
closesodoo/odoo#159957
X-original-commit: 695b3a687a3d160451339a675aab8986682389eb
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Steps to reproduce:
- Open the project in mobile view
- go to the kanban view enable task stages
- add one new staged with large name you can see name is
misaligned
Issue:
- In mobile view task stage name is misaligned
Solution:
- Adding class in able to not overflow name in kanban view
task-3602610
closesodoo/odoo#160540
X-original-commit: 7403bd65fd50c51d3a114a50f812a6f3740faa87
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Moves with a reversed payment_state are not included in the domain of the
"Paid", "Unpaid" or "Overdue" filters. This means that it is not possible to
display reversed invoices when using any combination of these filters.
In this case, it is preferable to be able to encompass the entire range of
possible states with a combination of filters. so rather than adding the
reversed payment state to the domain of the "Paid" filter (since reversed
payments aren't strictly "Paid"), this commit instead adds a new filter
"Reversed" with its domain set to include reversed payment invoices only.
closesodoo/odoo#160581
X-original-commit: 43a9b7afe4418fda10083fe7ced7744f0d93f79a
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Before this PR, the external live chat templates contained useless
parts, residus of the old live chat implementation. This makes the
live chat code harder to understand and to maintain. This PR removes
those outdated parts.
task-3852092
closesodoo/odoo#137574
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Problem: When the user sets a warning message for a product,
the message will always display even if the warning type is
no-message.
Purpose: The product's warning message should not display
if the warning type is no message.
Steps to Reproduce on Runbot17:
1.Install Sales
2.Enable Sale Warnings in Setting > Sales
3.Modify the sale warnings for a product
4.Create a quotation
5.Click on the catalog and look for the modified product
6.Observe the warning
Bug from commit: https://github.com/odoo/odoo/commit/a60cced44810d708beaf8ea5a166aa554a7c852b
opw-3806520
closesodoo/odoo#159795
Signed-off-by: Mylyna Hy (myhy) <myhy@odoo.com>
- Create a Partner who is a valid Peppol participant
- Clear their UBL format - they are still displayed as valid (Bug 1)
- Create an invoice for that partner and confirm it. The Peppol state changes to 'ready'
- Erase eas or endpoint on that partner and verify - the partner is now not a valid Peppol participant
- Reset the invoice to draft, confirm again: the peppol move state is still `ready`
1. Do not set a participant as valid if a peppol-incompatible edi format has been selected
2. Only save Peppol move state if it's processing/done already. Otherwise, let users clear it by resetting to draft.
(until we implement giving them control over this field)
opw-3784945
closesodoo/odoo#159852
Signed-off-by: Laurent Smet (las) <las@odoo.com>
This commit removes an unwanted `bg-primary` class applied to the change
password modal, making it weird and unconsistent regarding others modals
across Odoo.
=========
Steps to reproduce
=========
> Open a database
> Click on your avatar in the top right corner
> Click on `Preferences`
> Go to `Account Security`
> Click on `Change password`
>> The modal has a `bg-primary` class, making it look purple.
task-3836699
closesodoo/odoo#160462
X-original-commit: 2813540aba7556b915185e482cbb6d9500db7af1
Signed-off-by: Chrysanthe Gomrée (chgo) <chgo@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit when accepting a recurrent event from google calendar with option "this event", it didn't reflect on odoo calendar.
This happened due to the write_date check which applies google update only if their write_date is after odoo write_date,
but multiple updates from google might change some events write_date to now, which causes other google updates to get discarded.
This commit aims to fix this issue by keeping the write_date of the affected events before applying any google updates, and considering these dates instead of the live odoo write_date.
closesodoo/odoo#160357
Task: 3731552
X-original-commit: 3bcf6c458a4b483af6467d1c027b60771d1ce08d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If user changed quantity of products to amount that would create free
cart, without refreshing the page, they were still able to use express
checkout which was causing an error.
If user has free cart now, it will make express checkout button dissapear.
task-3568644
closesodoo/odoo#160386
X-original-commit: 0b47abaa6d682fb5c243d1b36dbed263343ce586
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: anko-odoo <anko@odoo.com>
Steps to reproduce
==================
- Go to Field Service
- Group by "start date: week"
- Archive every record in a column until there is only one left
- Go back to the kanban view
- Click on the single record from the column
- Archive it
- Using the breadcrumbs, go back to the kanban view
=> The group order is not preserverd and the empty one is the last one
Cause of the issue
==================
Before archiving the record, we have the following data:
`{group1: [1], group2: [2, 3]}`
After archiving the record, we have `{group2: [2, 3], group1: []}`
A new group is recreated from the old one, but it is always added at the
end.
Solution
========
We can insert the old group at his previous index.
The same solution was used in previous versions
opw-3816409
closesodoo/odoo#160121
X-original-commit: 0d44e931c40fbca005b8d1864cf2d07485ed84f8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently some VAT examples that contain other terms than only the
number are always displayed in English. This commit makes sure they can
be translated.
closesodoo/odoo#159724
X-original-commit: 504240b8633aac91eee421f3268550a1c04142a2
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Add a bunch of QOL improvements in the results page design:
NB: In order to stay stable-compatible, using "d-none" to
hide elements and using the "fs-x" class to resize the texts
instead of changing the header tags.
- Display the survey results page in half page size to prevent having too
much blank space between the tables columns
- The filter buttons are now displayed under the survey title
- Set the print button as always visible even on smaller screen sizes
- Show the leaderboard bar on the print preview
- Changing the eye dropdown icon to a caret for fold/unfold
- Align questions to the left to be on the same level as the sections
- Add an horizontal scroll to the matrix and simple/multiple choices tables
when the screen is not wide enough to display all the data
- Reduce vertical spacing between elements to gain space
- Reduce simple/multiple choices tables line height
- Reduce survey title, section title and KPIs font size
- Display the "Correct", "Partial", "Responded" and "Skipped" badges on a
single line under the question and set a rounded border around each badges.
- Fix the "Correct" and "Partial" display conditions
- Removing the "Result Overview" title
- Removing survey description, section description and question description
- Rename the "Maximum", "Minimum" and "Average" badges to "Max", "Min" and "Avg"
- When collapsed, hide the whole question on print preview
- When collapsed, only show the question title and hide the KPIs
Task-3707687
closesodoo/odoo#152263
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit fixes a layout issue inside the eCommerce categories form
view on mobile devices.
Prior to this commit, a `.oe_left` class was applied to the content of
the sheet, moving it "out of the flow", resulting in a wrong sized
`form_sheet`.
To fix the issue, we remove the `.oe_left` class, we apply a `.col-md-4`
`col-lg-6` to handle the width on large devices, and add a `.pe-3` to ensure that
the labels are not placed right next to the image in mobile.
task-3847917
closesodoo/odoo#160422
X-original-commit: 6aca24b14330b7681f8307f818135bd2bf71ab08
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Now, point_of_sale handles errors in partner editions, so it is not
required inheriting the method to add the functionality.
closesodoo/odoo#160389
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Currently, the emoji picker uses the `onWillUnmount` hook to detect when
the popover element is closed. The code defined in this hook accesses the
component's DOM and retrieves the scroll offset of the emoji picker's
scroll view. The scroll offset will then be saved and restored the next
time the emoji picker is opened by the user.
Unfortunately, it happens that the emoji picker's scroll view is no longer
in the DOM when the popover is closed and when the callback function
passed to the `onWillUnmount` hook is called. When this happens, the
system will log an error to the console (`TypeError: this.gridRef.el
is null`) and the user will not be able to reopen the emoji picker.
To fix this, we simply check that the emoji picker's scroll view exists
before retrieving the scroll offset of the element in the `onWillUnmount`
hook. This fix will prevent the error while keeping the code simple.
Steps to reproduce the issue:
1. Click on the article emoji
2. Click out of the dropdown to close it
3. Click on the article emoji again
=> The emoji picker no longer appear.
TO BE: The emoji picker should reappear when the user clicks on the emoji.
task-3818728
closesodoo/odoo#160353
X-original-commit: 6ae04b576a3f3b74febf029383c0f6d9ca5744cf
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Julien Banken (jbn) <jbn@odoo.com>
Currently, when making a manufacture order, the duration for operations is not computed when time was not tracked.
Steps to reproduce:
-------------------
* Go to the **Manufacturing** App
* Under **Products**, select **Bill of Materials**
* Create a new bill of materials
* Add any product
* Add any component
* Add an operation
* Select any work center
* For `Duration Computation`, select `Set duration manually`, set any amount
* Save everything
* Under **Operations**, select **Manufacturing Orders**
* Create a new order
* Select the product for which the bill of meterial was created
* Save > Confirm > Mark as done
> Observation: Real duration is showing 0, instead of the manual amount.
Why the fix:
------------
As of now, the duration only depends on the time tracked on each operation.
https://github.com/odoo/odoo/blob/7a9b05e5e7ccc54fe673a00167a261c2c6181d0a/addons/mrp/models/mrp_workorder.py#L318-L321
The issue was solved in upper versions with this fix: https://github.com/odoo/odoo/commit/5e2b97b47f3cf14616c24631acf2cd08f0295a43
I'm backporting this fix for consistency even though the issue it was originally for does not exist in 16.0 but it still solves the fact that the duration isn't computed if time was not tracked.
opw-3800477
closesodoo/odoo#160372
X-original-commit: 20cc428f6a0459587ba241086040626a5818f53b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Sarah Bellefroid (sbel) <sbel@odoo.com>
Reproduction steps:
- disable any debugger parameter that would on in the url
- create a new sale order
- add a sale order line with a tax
- save (and don't leave the record!)
- delete the sale order
Regarding the bug, there are several issues happening at the same time:
- Business code issue:
- Our code wasn't defensive and we were assuming the computed value
would always be set to the computed value.
- Framework JS issue: (not OWL itself but its integration into Odoo)
- When the record is deleted, a re-rendering gets triggered.
- As we deleted the record in the back, the browsed record in the
front-end gets its data reset to the default values a field could have.
Because the default value of a binary field is False, tax_totals gets
set to false for the reset record.
Now, we have a bunch of race conditions going on.
In the invoicing view, it doesn't happen because the rendering is slower
and it gets cancelled before being done. Thus the field tax_totals
hasn't the chance to re-render itself and thus, to call
TaxTotalsComponent.formatData through the call of onWillRender.
In the case of the sale order view, the field has the time to gets
rendered, the method gets called and the traceback happens.
closesodoo/odoo#159018
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Issue
-----
The tooltip help text doesn't match the actual calculation made in the product margins report.
opw-3792181
closesodoo/odoo#160375
X-original-commit: aa8a769d5bc15e01ae1f37271d16c42e4d18df40
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Accounts 10x -> 13x should be of 'equity' type.
(In the Balance Sheet, they are referenced under the Equity section.)
opw-3743637
closesodoo/odoo#160324
X-original-commit: cfb474a7081f5b123bf27a5234d2d11819f19011
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
- replace order summary by a dropdown like mobile view
- remove 'Pay With' title
- match 'Choose delivery method' style with 'Choose payment method'
- make order summary sticky so that 'Pay now' is always accessible
task-3741412
closesodoo/odoo#154035
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
People may have used a m2m where we don't really want a m2m relationship.
Task-3605612 (WhatsApp: Fix header / upload / reporting usage)
closesodoo/odoo#160332
X-original-commit: 910e41baf0d6ab558c53d41e511b3f10bf9860ad
Related: odoo/enterprise#59987
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Deleting a partner may take a long time because odoo has to check an
entire table to find few records or no records at all that reference the
partner and set it to null.
So we are adding an index btree not null to speed up the deletion of
partners.
closesodoo/odoo#160184
Task-id: 3759406
Related: odoo/enterprise#59932
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Having the VAT VIES Check valid field directly next to the VAT number
as an inline element becomes unreadable, so we wrap it add padding and text-nowrap
closesodoo/odoo#159332
Signed-off-by: William André (wan) <wan@odoo.com>
This commit reverts odoo/odoo#133504, as it was deliberating access to private
event information to uninvited administrators in the calendar view. Only the
event organizer and its attendees must be able to fetch private events information.
In addition, two tests have been added to: 1. ensure the confidentiality of
private events from uninvited administrators and 2. prohibit uninvited
administrators from edit the information of any event, private or not.
task-3837646
closesodoo/odoo#160308
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
The `website_livechat.chatbot_redirect` tour checks that the chat bot
still works after redirection. The tour waits for the chat bot message
that indicates the redireciton was made. Since the tour restarts the
bot to test two differents flows, this message is already present
before the second redirection occurs. The tour should instead wait for
two occurences of this message the second time.
closesodoo/odoo#160296
X-original-commit: cfdcdc405751e2d8d81dbbec34894d3da9c005ef
Signed-off-by: Didier Debondt (did) <did@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
This commit improves the UX of the color picker's hex input in two ways:
- If the user enters a hex color without the "#" symbol, it's
automatically added.
- As soon as a valid hexadecimal color is entered in the input, the
colorpicker updates, and the color is applied to the target element.
task-3747408
closesodoo/odoo#157034
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Before this commit, clicking in the area below the "Hex color" input
would close the color picker. This was annoying when entering a value in
the "Hex color" input and then clicking below to confirm it.
After this commit, the color picker no longer closes when clicking on
its background.
task-3747408
Part-of: odoo/odoo#157034
Steps to reproduce the issue:
=============================
- Go to website and open editor
- Click on the 'Contact Us' button
- Change the color of the text
- error
Origin of the issue:
====================
`HistoryReverCurrentStep` will call `observerFlush` which will mark
`_toRollback = true` and in `_observeOdooFieldChanges` we will update
the html with `withoutRollback` but this only works only if
`_toRollback` is `false`.
Solution:
=========
We need to rever the step without rollback too.
task-3770287
closesodoo/odoo#156461
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This route is no longer used in our code and it tries to read templates
that are no longer existing, leading to a crash if called manually.
closesodoo/odoo#160277
X-original-commit: 130ac07ccf14cca3d9dd4e0cd897e00d1c0b6055
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
In `ir.model.data` model, there is no SQL constraint which is
ensuring that the `name` field can not contain `.` (dot)
So when loading the translations to database if the xmlid's `name`
contains dot then `xmlid.split('.')` will split it more than 2 parts.
Which will cause issue during saving it to database as it is expecting
2 parts `[<module>, <name>]`. I ensured the splitting to 2 parts
with `maxsplit=1`
closesodoo/odoo#160228
X-original-commit: a1ae06f499b183db69b7e763a2803a079f540a77
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
If an error happens when a website page is being saved, the error
message was displayed as a popup on the edited block.
Since [1] that error was not displayed anymore because the call to
`ir.ui.view`.`save` from `this._rpc`, which wrapped errors into a
message, was changed to `this.orm.call`, which raises errors in their
original form.
This commit adapts the error handling to expect an actual error instead
of a message.
[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997
task-3599890
closesodoo/odoo#155071
X-original-commit: 7d5aeabebbc56ac22d06e8291e1cf58b62d4defe
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before this commit, when the clickbot detected an error dialog, it
stopped the test and throw an error saying that an error dialog was
detected. This information is not enough to check why, and how, the
error dialog was produced.
Now, we also log the content of the error dialog as well as all the
information of the last rpc that was in error.
closesodoo/odoo#160103closesodoo/odoo#160272
X-original-commit: 4f26b324a30c5120ea60b6b42fef6cd6000d2859
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This is done together with an enterprise commit in order to avoid creating mail alias automatically on journals imported via FEC files, in France. Indeed, such files could contain journals with different codes but same name, each of which would try creating an alias with the same name, raising an error.
OPW 3813584
closesodoo/odoo#160168
X-original-commit: 16c305dd3ceda91a84ae073dc1252891bf7af390
Related: odoo/enterprise#59921
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Issue:
- When printing a Payment Receipt the name
"INV0001" is added to the title.
Steps To Reproduce:
- Accounting > Vendors > Payment
- create new payment and print payment receipt.
Solution:
- The issue was using a self-closing <span> tag and
incorrectly placing the INV0001 placeholder outside it.
- I placed INV0001 within an opening
and closing <span> tag for correct dynamic content replacement.
opw-3820212
closesodoo/odoo#159915
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Currently, when generating the invoice from the PoS shop, the invoicing address of the partner is not used. This differs from the invoice created using the sale app which uses the invoice address.
Steps to reproduce:
-------------------
* Go to the **Contacts** app
* Select any contact (ex: Azure Interior)
* Under **Contacts & Addresses** select Add
* Select **Invoice Address**
* Write the address then **Save & Close**
* Go to the **Point of Sale** app
* Add items
* For customer, select the contact we just modified
* Select **Payment**
* Select any payment method
* Select **Invoice**
* Validate
> Observation: The invoice address is not used
Why the fix:
------------
We observe a discrepancy between the sale and pos output for the same workflow.
* Sale
* Sale order form: `Customer` -> Azure interior (Has a field for invoice address)
* Account move form: `Customer` -> Azure interior, Az inv (Use the invoice address)
* PoS
* PoS order form: `Customer` -> Azure interior (Does not have a field for invoice address)
* Account move form: `Customer` -> Azure interior
In stable we can't add the invoice address on the PoS order form but we can still stay consistent with the sale workflow in terms of account move.
In the sale workflow, the move is created with `invoice_vals_list`
https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L1207
Having a look at `invoice_vals_list`, we can see that the customer_id is set using the invoice contact address.
https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L1004
With `partner_invoice_id` computed as follows:
https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L340-L342
Thus, we also send the invoicing contact address as partner_id when creating the move in pos;
opw-3797434
closesodoo/odoo#160154
X-original-commit: ab904c7e06f481f28cd581b9e677d0db9bf608f1
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
If user had less than 1 point, which is equivalent to 1 quantity of set
currency, on gift card and eWallet, they could not use it due to not enough point on
Gift Card and eWallet for claiming reward.
opw-3667934
closesodoo/odoo#159984
X-original-commit: 64711a9152b6bb661392882d3403c194f5990fbc
Signed-off-by: anko-odoo <anko@odoo.com>
When the aggregated value is 0 (9000 + -9000 = 0), it displays an empty cell
in spreadsheet, instead of zero.
closesodoo/odoo#159148
Task: 3827502
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Follow-up of [1] which changed code in stable in such a way it could
break when the function was used in a way it was not intended to in
some custom code. Note that the function could also be used by giving a
string selector to it, that will not work anymore: but instead of
crashing, this commit will just make it do nothing (it is only about
adding a button loading effect anyway).
[1]: https://github.com/odoo/odoo/commit/8bd51d060a48378652ae10c57a1949c3bb7d78declosesodoo/odoo#160253
X-original-commit: d703125766d27ff33659c38fa50c2266f5f3dabb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Standard `sale` tax flows rely on `_get_tax_included_price_unit`,
whereas part of `website_sale` flows do, while another part relies
on `_fix_tax_included_price_company`, which doesn't handle some
advanced cases (fiscal position mapping of price_included taxes).
This commit drops the use of `_fix_tax_included_price_company` in
website_sale, to only use the newest API of `_get_tax_included_price_unit`,
supposed to handle more cases.
Also makes all taxes computation go through a single entry point,
`_apply_taxes_to_price`, already used for `combination_info` logic (/shop/product),
but not in `_get_sales_prices` (/shop page).
opw-3700803
original commit : 662ea281515156a781ab68079d0123ea45ebf40f
closesodoo/odoo#160198
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
separate the true computation of the tax value from the computation of the base unit price (uom & curr conversion, ...).
That way, the risks of unwanted side-effects is reduced when the base unit price is already computed (sale, website_sale).
Also allows preprocessing the taxes mapping, which doesn't have to be done multiple times when we compute different amounts for the same product/template.
original commit: bc79770d1e00cf86a46002d633afd8b32921610b
Part-of: odoo/odoo#160198
Before commit:
Long user names in direct messaging search are not wrapped, leading to
UI display issues.
After commit:
Resolved the issue where long user names were not properly wrapped in direct
messaging search. Now, when a user name exceeds the allotted space, it is
truncated.
Task-3748791
closesodoo/odoo#160141
X-original-commit: eaf0e073ef8689629541de33e9bcf167f0e6b8e8
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- Install MRP
- Enable packages and multi-step routes
- Enable two steps manufacturing
- Create a component and a product
- Create a BOM for the product and add the component
- Make an MO for 100 units of the product
- Go to the picking and make a move of 20 units of the component with a
destination package
- Put in pack
- Create the backorder and validate the transfer of the remaining
components
- Go back to the MO
Issues:
Units reserved is wrong. The problem is when we are unpacking, we were
using result package inside the key. But what we want is to remove
quantity from the package the quantity originate from.
opw-3759006
closesodoo/odoo#160091
X-original-commit: 1cc04382f7ebaaa68ebe9313f1cd6b1284e13665
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Mattis Megevand (mmeg) <mmeg@odoo.com>
Steps to reproduce:
- Install Accouting and Expenses
- Activate "Analytic Accounting" in Accounting settings
- Go to "Accounting / Configuration / Analytic Accounting / Analytic Plans"
- Create an analytic plan with the following line:
* Domain: Expense
* Applicability: Mandatory
- Create an analytic account from the plan via "Analytic Accounts" smart button
- Create an expense without analytic
- Create a report from it
- Submit it to manager
- Try to approve it
=> An expected Validation Error will raise:
"One or more lines require a 100% analytic distribution."
- Go to "Expenses / Expense Reports" (list view)
- Select the created expense report
- Try to approve it
Issue:
The report will be approved even if there is no analytic configured on it.
Cause:
"validate_analytic" option is not passed in the context when approving the
report from list view as it is done in form view.
opw-3806787
closesodoo/odoo#160143
X-original-commit: f25a1192454b988f90d454ad9a2706de1415a2ee
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Issue:
When applicant retakes the survey, we only see the first answer of the applicant
from -Consult Interview- smartbutton from the applicant form.
Desired behavior:
We should see the latest answer
closesodoo/odoo#159833
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Odoo implements its own lazy-loading mechanism for the biggest JS
bundles that are loaded on the frontend. This mechanism allows the page
to appear to the user very fast, at the downside of having some
interactive elements (such as buttons) have no effect during the lazy
loading. In general, this is not a problem since:
- Standard links and buttons work, only those with custom effects (a
modal, a custom JS behavior, etc) have no effect.
- The full loading should not take long anyway.
- After the pages have been visited, everything should be in cache.
However, in some cases (countries with poor internet connections), the
experience can be confusing. Without lazy loading, they would have a
page that appears as a blank white page for a few seconds. With our
custom lazy loading, they get the website very fast... but some buttons
appear buggy (no effect) for a few seconds.
The long term plan is to review our lazy loading:
- Should it be less delayed than it currently is? (at the time, this was
the minimum delay that made Google give us good page scoring but it
may not be as impacting as before)
- Should some of the lazy-loaded JS should actually not be?
- Should the assets be split differently?
- Could we be able to remove some code that weighs too much?
- ...?
Meanwhile, this commit improves the behavior this way: during lazy
loading, any click on a button is now ignored but a loading effect is
displayed. Once the JS is fully loaded, the click is then re-played on
the previously clicked button, hopefully triggering its effect. In any
case, this cannot be worse than what we have before... except for:
- The reasonable risk we take merging this in stable (we considered
merging in a more recent version but it is needed for some specific
projects and many websites would benefit from this improvement).
- Any custom code that added behavior on buttons to be available during
lazy loading... will just wait for lazy loading with a loading effect
too now. This should be a good compromise as, again, that lazy loading
is cached and should not take too long anyway.
Note that this replaces the previous o_wait_lazy_js class behavior (it
has now no effect).
Overall:
- This should not impact (neither improve nor worsen) most websites that
are currently experienced from good internet connections.
- This should be a big improvement for most websites that are currently
experienced from bad internet connections.
Related to task-3770362
closesodoo/odoo#159680
X-original-commit: 6aeebe47dd552144fabd42ddb190021f1499e38a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
As a preparation for the upcoming improvements in the lazyloader, this
moves the code around a bit. This will ease the review later. This
also actually removes code that was totally useless in that moved code.
Related to task-3770362
X-original-commit: aef5a7631723f3e26425427a963c1a0dd7b6d133
Part-of: odoo/odoo#159680
Julien Carion (juca)