Before this commit:
Using the "Download logs" button from the IoT box form view will
fail every time due to an Internal Server Error on the IoT side.
```py
File "/home/pi/odoo/odoo/tools/misc.py", line 189, in file_path
FileNotFoundError: File not found: /var/log/odoo/odoo-server.log
```
This happened due to changes introduced in:
https://github.com/odoo/odoo/pull/99658
The changes enforced to double check that the file path was in an
odoo addons (for security reasons).
However, it is generally not the case, thus the error
After this commit:
The log file is downloaded as intended
opw-3827121
closesodoo/odoo#160576
X-original-commit: a7aa4c6e58d6448556c85c393f2910490a0519f5
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
Currently, when you copy the viva wallet webhook to
configure it in your account, you have to select it manually.
With this commit we add a “CopyClipboardChar” widget
which does this automatically.
closesodoo/odoo#160516
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Create an expired loyalty program with code
Open POS session
Add product
Apply code
Issue: code is applied even if expired
opw-3624670
closesodoo/odoo#145609
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
A partner found a bug, when this public method is called on a recordset
of more than one journal then the restriction will traceback, as the
`id` can only be called on one journal.
Simplest solution is to simply get `id` on the loop variable instead,
and let the code normally block the user with a UserError.
Credits to: https://github.com/juppe
Old PR: https://github.com/odoo/odoo/pull/150888closesodoo/odoo#160585
X-original-commit: a0ca663b78741a82fcc8f4bea97779aa97087754
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
-Before this commit the url is like /blog/1/feed then it will become a
redirect 301 url to /blog/travel-1/feed which is not good for SEO.
Therefore we change to slug(blog) to ensure no redirect occur
closesodoo/odoo#160583
X-original-commit: 3192d2d531e918a705aee2341881a80294f848dd
Signed-off-by: Jérémy Kersten <jke@odoo.com>
*: test_mail_full, website_blog
Steps to reproduce the bug:
- Enable the comments on a blog.
- Add a comment.
-> Problem: The avatar of the comment is the default placeholder image.
The problem appears since [1]. This commit was created to bypass the
read access of an image if a correct `token` was provided in the dataset
of the `.o_portal_chatter` element. The problem is that since [1], if
the `.o_portal_chatter` element does not have a `token` (or a `hash` and
a `pid` since [2]) in its dataset, the avatar images are displayed as
the default placeholder image by default. The goal of this commit is to
correct this behavior; if there is no token provided, the previously
used `/web/image` route is used to show the avatar. Thanks to this
route, the avatar is displayed if the read access is fulfilled. If it is
not the case, the default placeholder image is displayed.
[1]: https://github.com/odoo/odoo/commit/d4eb996cd3caea3fbb822437057a6a5a8a722293
[2]: https://github.com/odoo/odoo/commit/7f69708bcce3b3c4b096d89cb0ec354998eac191
opw-3749422
closesodoo/odoo#160240
X-original-commit: https://github.com/odoo/odoo/commit/c65cffd6447afce65a45a38690c003e84afd63d9
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Use case:
- Create a Kit BoM with finished qty to 5 consuming 10 components
- Do a sale order for 3 units (3/5 of BoM)
- Update the sale order line to 4 units
Current behavior:
The delivery has a huge amount to deliver
Expected:
The delivery is for 8 units
It happens because the method `_compute_kit_quantities`
always expect a BoM for 1 units.
`bom_line_data['original_qty']` always contains the number of times the
BoM will be needed and not the quantity of finished products.
In order to have the number of component by unit of finished product we
have to introduce the BoM quantity in the formula
closesodoo/odoo#160149
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Commit [1] resolved an issue related to the behavior of small font sizes, which
caused 'NaN' to appear in the font-size dropdown within the floating toolbar.
This occurred due to the removal of a variable definition, resulting in the
inability to compute the font size. This commit rectifies the problem by
reintroducing the variable in the SCSS file to ensure correct rendering.
[1]: 7931d1a14a
task-3801894
closesodoo/odoo#158811
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
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>
Loan (LSE)