The VAT rate is increasing from 20% to 22% from January 1st, 2024.
We need to keep both 20% and 22% taxes until the end 2025 for phasing out period.
20% taxes will be inactive for new customers.
task-3615036
closesodoo/odoo#147331
X-original-commit: 2c41415f1010fac3bfcc510fc08f659cfe009420
Related: odoo/enterprise#53321
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Steps to reproduce:
- Install Accounting
- Activate a payment provider (e.g. Stripe)
- Configure payment provider with "Capture Amount Manually" option activated
- Invoice Online Payment in Accounting settings
- Create an invoice
- Go to invoice portal preview
- Pay it via "Pay Now" button
- Go back to invoice portal preview
=> The "Pay Now" button is still there (not expected)
- Uninstall "account_payment_invoice_online_payment_patch" module
- Go back to invoice portal preview
=> The "Pay Now" button does not appear anymore (expected)
Cause:
"account_payment_invoice_online_payment_patch" module has been created to
allow to disable invoice online payment without uninstalling "account_payment"
module.
However, it overrides 2 different "t-if" conditions:
1) (invoice.amount_residual or not tx_ids) and
invoice.state == 'posted' and
invoice.payment_state in ('not_paid', 'partial') and
invoice.amount_total
2) invoice.state == 'posted' and
invoice.payment_state in ('not_paid', 'partial') and
invoice.amount_total and
invoice.move_type == 'out_invoice' and
(pending_manual_txs or not tx_ids or invoice.amount_paid < invoice.amount_total)
with the same condition "invoice._has_to_be_paid()" that corresponds to:
(self.amount_residual or not transactions) and
self.state == 'posted' and
self.payment_state in ('not_paid', 'partial') and
self.amount_total and
self.move_type == 'out_invoice'
One part of the second "t-if" condition is removed by the override:
(pending_manual_txs or not tx_ids or invoice.amount_paid < invoice.amount_total)
The second condition is used and is overridden 2 times.
Solution:
Add (pending_manual_txs or not tx_ids or invoice.amount_paid < invoice.amount_total)
in the "_has_to_be_paid" method.
opw-3378400
closesodoo/odoo#147316
X-original-commit: df110bb524f780433cdaf64e482329989e9d513b
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Before this commit
================
- Portal users were not able to download the return label via the portal because
the Access token is not passed.
After this commit
================
- Portal users are able to download return labels via the portal.
task-3245766
closesodoo/odoo#147315
X-original-commit: 2b9fe4854078e237b5da7e97e4ff3fa8d6c270a9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, in a non-editable x2many in list mode, if there
is a field "A" with many2many_tags which is displayed as an x2many
in list mode in the form dialog, it cannot be reordered with handle field.
Problem:
When we extend a record from an x2many to a form dialog, we use the
activeFields defined in the form view and patch them with those in the
list view. Currently, we always use the default order from the list view
even if it doesn't exist. So we always ignore the one defined in the form view.
Solution:
If there is no default order in the list view, we use the one in the form view.
How to reproduce:
- Go to a form view with an x2many field in list mode which contains
an "A" field with the many2many_tags widget.
- Click on a record in the x2many
- A form dialog opens with field "A" in the form of an x2many in list mode,
containing a handle field.
- drag and drop a line to reorder the records
Before this commit:
It is not possible to reorder records
After this commit:
It is possible to reorder records
Task ID: 3641933
closesodoo/odoo#147253
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Current behaviour:
When setting a form to fullscreen,
it doesn't save.
Steps to reproduce:
1. Go to eLearning
2. Select a course
3. Add Content, type Web Page
4. Select it, Go to website
5. Drag and Drop a form in the middle
6. Click on Fullscreen
7. Try to send the form
8. An error has occurred, the form has not been sent.
Cause of the issue:
Caused by: https://github.com/odoo/odoo/commit/17c6f6f30bf13bd3c303b28d9a314bd76dd8f4dc
When using a form normally, website_form_signature is added by
add_form_signature in the page, because rendered through XML.
When using a fullscreen form, website_form_signature is not added,
because the page is rendered through JS.
Fix:
Calling ir.qweb.field.html in the JS route which calls
value_to_html (in website) which calls add_form_signature
Concerning {'template_options': {}}, without it, when we call
_post_processing_att with the argument options.get('template_options'),
because options are empty, it returns None, and in _post_processing_att
when doing options.get('inherit_branding') we get a traceback.
Since in 16.0, options are not used either in value_to_html
nor _post_processing_att, it is no use to fix their modules.
opw-3611126
closesodoo/odoo#147197
X-original-commit: beb1200d31ea0fc3ae4261b50018d9f56c275cc3
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
When the payment reference is set as the customer reference, the warning message of the
transaction still show the order reference instead.
With this commit, we now ensure the expected reference is shown instead.
opw-3461181
closesodoo/odoo#147143
X-original-commit: f25537dc83a6cb9193f78ab8f32c94a541fade0e
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Steps to produce:
- Go to project application and create a new task with SO.
- Select a customer that has prepaid hours product.
- Check that remaining hours on SO is less than 0.
- Share that project.
- Go to front-end.
Issue: The value of 'remaining hours on SO' should be displayed in red
if the value is negative
Cause: Necessary class was not added to the field
Solution: To resolve this issue added decoration-danger when remaining
hours so is less than 0.
task-3549489
closesodoo/odoo#146948
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
- Create Allocation for 20 days for Mitchell Admin and validate (12/01 to 12/31).
- Set Working Schedule "Standard 40 hours/week" to UTC timezone.
- Set Mitchell Admin's timezone to Europe/Zurich.
- Create a time off with type Extra Time Off with dates 12/29 - 12/29 and try to save.
- Receive Validation Error: There is no valid allocation to cover that request.
Issues:
You cannot request that leave due to a timezone mismatch, even though you should be able to.
Solution:
To solve the zone mismatch we use the employee timezone to compute the
attendance intervals.
opw-3619178
closesodoo/odoo#146938
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Before this commit if invisible elements are in the DOM (e.g.
device-visibility restricted) the arrows to move snippets (columns,
sections) did show up and behave as if the neighbour elements were
visible.
This commit hides arrows that would not visually move the snippet, and
upon using the move arrow, it also moves the snippet beyond the first
visible neighbour.
Steps to reproduce as of 16.0:
- Drop a "Columns" snippet.
- Make the center column hidden on desktop.
- Move the first column to the right.
=> It did not move and an arrow to move to the left was displayed.
Steps to reproduce before 16.0:
- Drop three snippets.
- Make the second snippet conditionally visible.
- Hide it using the eye icon in the "Invisible Elements" list.
- Move the first block down.
=> It did not move and an arrow to move upwards was displayed.
task-3584947
closesodoo/odoo#146879
X-original-commit: 60e2a5bc9ed8721ed34eb952cd34375fe5a93395
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Prior to this commit, `ButtonBox` components were rendered inside
`Dialog` ones.
The approach created issues in the user flow, particularly in cases
involving intermediary records that were not yet saved yet.
task-3619180
closesodoo/odoo#146797
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When we add a new record N to an one2many tree view from an existing
record X form, during the onchange() on the one2many comodel, the cache
of the N.one2many contains only the new record X (the siblings aren't in
it). Because of this, the result of compute methods may be incorrect
and the form won't be updated accordingly. See
https://github.com/odoo/enterprise/pull/52957 for a concrete example.
Technically, this is due to _update_cache() forcing the inverse field
value to the single value of the new record
("not cache.contains(inv_rec, invf)" is True), instead of also
considering the original values (which is properly done by
Field._update()).
closesodoo/odoo#146778
Related: odoo/enterprise#53298
Signed-off-by: Raphael Collet <rco@odoo.com>
In a Manufacturing Order based on a BoM, changing the qty values
and then change the scheduled date will reset the qty to the bom ones.
This should not be the case.
Regarding the test, setting the date before the bom_id ensure that the date will
be set when we enter the _compute_move_raw_ids.
enterprise: https://github.com/odoo/enterprise/pull/51822
opw-3568943
closesodoo/odoo#146508
X-original-commit: 780dded
Related: odoo/enterprise#52892
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Since its introduction with commit [1], the blog post teaser is not
translatable as the field was not set as `translate=True` by mistake.
It's not possible sadly in stable to add it since the jsonb introduction
for translated fields, as `translate=True` behaves as a DB change.
Without a module update, it will crash, trying to set jsonb value in a
non jsonb field.
A best effort is make here to add a tooltip to hint what's going when in
translate mode and clicking on this field text.
Note that the field is not marked as translatable, but if people click
on it, they will see the tooltip.
If we face multiple needs, it might be clever to introduce a new
property on field declaration allowing the mark a field as "translate
forgotten" so that our builder shows this warning out of the box.
Step to reproduce:
- Install 2 langs on website
- Go to /blog in the main language and enter edit mode
- Type something on a blog card below the cover (it should show by
default the first few sentences of the blog content)
- Go to the alternate language and enter translate mode
- The field is not maked as translatable and can't be translated
[1]: https://github.com/odoo/odoo/commit/8cc850f3a54f62072d4df99de612f17494ffb123#diff-ae5c21b812e929930064fb93dc919ef1701fd63bae3d9fb306160d01be5629b3R114-R115
opw-3474638
closesodoo/odoo#147287
X-original-commit: abc5e3c119b74691949c7f48d3b7ba1f9fc88626
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Following the event badge redesign in odoo/odoo@1da6cbc4c, we should
display on the attendee's badge (report) the attendee's company name
(`company_name`) instead of the event's company (`company_id`)
closesodoo/odoo#147272
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behavior:
When you add multiple note in a sale order, only the last one was taken
into account in the POS. Now we show all notes on the ProductScreen and
on the ReceiptScreen.
Steps to reproduce:
- Install pos_sale
- Create a sale order with a product and 2 notes
- Open the POS and load the sale order
- Only one note appears under the product
- Validate the order
- Only one note appears on the receipt under the product
opw-3551331
closesodoo/odoo#146891
X-original-commit: f7c5e7fd772d9700fe16589eea0ad51dda873c5f
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Before this commit, the helpers for the kanban view are only used
in the kanban tests in web module and those helper functions are not
exported and so it is impossible to use it outside that file.
This commit moves the helper functions for the kanban view in a new file
called "helpers.js" in the same directory containing the tests for the
kanban views and export all the helper functions to be able to use it
anywhere we need to use those helpers in JS tests.
closesodoo/odoo#147279
Related: odoo/enterprise#53040
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- In Settings/technical/actions/reports: find the invoice report
- in advanced: activate "Reload from attachment"
- create an invoice with a swiss customer
- confirm and print
- print the invoice again
Issue:
There are two pages with the same qr-code
opw-3626815
closesodoo/odoo#147281
X-original-commit: a6e06531cdd15736b6ed51702e6ba17fb73fe89d
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Before this commit, the layout of the import module form view (in
the dialog) was broken. This was due to unnecessary and wrong use
of col/colspan attributes.
closesodoo/odoo#147271
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
From the first of January, Ticketbai becomes required in
the region of Batuz (Bizkaia).
And we were missing a piece where also the vendor bills
need to be sent, similar to SII (but different)
For that, they use an LROE structure, which we also used
for sending customer invoices, but with the regular Ticketbai
XML in there (encoded in base64).
For vendor bills, it is however not the regular Ticketbai
XML and the chaining and signature are also not needed, but
the enveloping structure is built in the same way.
So, we activate Ticketbai by default on vendor bill journals,
but it will only be sending when the agency is Batuz.
Thanks to Moduon and Landoo for the extra push.
opw-3628750
closesodoo/odoo#146625
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Create a new live-session survey with a multi-choice question of 4
choices. In one of the choices write a word of 20+ characters. Start the
live-session, on the manager side the choices overlap on the screen.
In case a word is longer that the available place, it can overlap on the
labels of the other columns, making the text very hard to read. This
work wraps words that are too long for a single line over multiple ones.
Task-3530706
closesodoo/odoo#146554
X-original-commit: f085957855f86fb669c533be09fd13a14a6c874d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Current behavior:
When trying to print the changes of an order, nothing was printed.
This was happening because we were first saving the changes before
sending them to the printer. Because of this when we tried to retrieve
the changes to print them, they were already saved and we were not
retrieving anything.
Steps to reproduce:
- Setup a printer to print order changes
- Create a new order in PoS restaurant
- Add a product to the order
- Click on the "Order" button
- Nothing is printed
opw-3625397
closesodoo/odoo#146461
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In list views with search panel, in case there are no records found,
the nocontenthelp is being cut off,
because the o_list_renderer doesn't take the full height.
This commit sets the height on the div, so there is no cut off happening.
Part of: task-3619987
closesodoo/odoo#147268
X-original-commit: 52c916089547c96c2d16c0c6134b40270b72b72d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Currently, categories' images can only be seen while logged in. This fix will allow public user to have access to images.
Description of the issue/feature this PR addresses: add access rights for booth category for public user
Current behavior before PR: images of booths' are not loading if not logged in
Desired behavior after PR is merged: images of booths' are loading regardless of the user
opw-3625773
closesodoo/odoo#147267
X-original-commit: 1599e5c3c004e439e8ff45dfc40a92a045a66c21
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Before this commit:
Filter items in the sidebar/panel are sorted DESC. Items without value
are put at the end of the sorted list (eg : Open Shifts)
After this commit:
Filter items are sorted ASC. Label that begins with numeric are also
sorted correctly. Items without value are stull put at the end of the
sorted list.
task~3524031
closesodoo/odoo#146127
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Task latam: 1137
Task Adhoc: 33333
Prevent delete document number if invoice date is assigned (manual documents).
Description of the issue/feature this PR addresses:
On a draft vendor bill (manual documents) if the document number setted, and then if the user set a date, the document number is automatically cleaned and it`s must not be cleaned.
Current behavior before PR:
On a draft vendor bill if the document number setted, and then if the user set a date, the document number is automatically cleaned.
Desired behavior after PR is merged:
On a draft vendor bill if the document number setted, and then if the user set a date, the document number is not automatically cleaned.
closesodoo/odoo#147242
X-original-commit: 8212f7dd73028fa6c68819218e1e63fe60d71913
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce:
Go to the website's home page > Site > Properties > The control panel
buttons in the footer of the "Page Properties" dialog are not aligned
correctly.
The "Page Properties" dialog extends the `FormViewDialog` component and
updates its template using `xpath` to add extra buttons on the right
side of the footer (to "duplicate" & "delete" the current page).
But since [1], a `w-100` class has been added to the default button
container (`.o_cp_buttons`) on form view dialogs to get the same result
as the "More Options" button on `Calendar > Quick Create` dialogs (the
difference here is that the extra button was added inside the default
buttons wrapper, while on page properties, the buttons are added next
to it).
The goal of this commit is to "safely" fix this misalignment issue on
stable by simply removing the `w-100` class for the page properties
dialog. On master, we will adapt the page properties buttons to have
the same structure as on the calendar dialog.
[1]: https://github.com/odoo/odoo/commit/7dd6e5d1a55de99a4212abc6f24490e47d9ce5bb
task-3642712
closesodoo/odoo#146541
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Phone and mobile numbers are not well displayed
on contact widget..
This is because of the display flex that split
the column in two if there is too much information.
We remove the display flex + flex column as
all the children of the element are div, which is
a block element, therefore they are already arranged
one on top of the other.
Steps:
- Having a contact X with full address informations
(address, name, phone)
- With purchase module, you see the bug by
printing a RFQ for the contact X
opw-3626486
closesodoo/odoo#146455
Related: odoo/enterprise#53201
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
This commit involves reorganization of demo data in the Indian localization
modules.
Specifically:
- Removed demo data entries.
- Added new demo data entries for improved examples.
task id: 3614544
closesodoo/odoo#144951
Related: odoo/enterprise#52104
Signed-off-by: Josse Colpaert <jco@odoo.com>
steps to reproduce:
- install the module "2FA by mail" (auth_totp_mail_enforce)
- open settings (this should bring the settings of the settings app)
- activate "Two-factor authentification enforcing policy" to "Employees only"
(or "All users") and save
- try to (re)connect with a user (demo/demo or admin/admin)
before this commit:
- internal server error
after this commit:
- error is passed to the user, allowing him (or the admin) to
debug without contacting odoo support
opw-3624816
closesodoo/odoo#147196
X-original-commit: a449210cc18f64460096cb43b3633d4861120d0e
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit:
Got a traceback instead of an error message on scanning a barcode.
Reason:
Until 16.4 error message send in the object via Eventbus, which removed in
https://github.com/odoo/odoo/commit/72dbb75d4de529a35c45273ded472d038a7bb738 so because of that error message will be sent directly(not in object).
After this commit:
User will get an error message if anything wrong happened.
Task:3524284
closesodoo/odoo#138877
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Fix a small issue with the trusted account lock system, where we would raise an error
when you change the partner or account number on a record at the same time as you untrust it.
Before this fix it would be blocked, and you would need to untrust, save, and then redo the
change in a second edition for it to work.
At the same time, we will allow the process to untrust an account and change values at the
same time.
Task id #3647635closesodoo/odoo#147089
X-original-commit: 3815ccea98c95130a770772aa29c87112e695914
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Description of the issue/feature this commit addresses:
On the first of Janurary 2024, Indonesia will use 16 digits VAT numbers in
addition to 15 digits ones. This commit makes it possible to use any of these
two possibilites when entering the VAT number on an indonesian company.
Desired behavior after this commit is merged:
This commit makes it possible to enter either a 15 or 16 digit VAT Number on
an Indonesian company.
task-3636748
closesodoo/odoo#147215
X-original-commit: aae3495334f02eaf43e0396b040b75c926406fbd
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Thomas Becquevort (thbe) <thbe@odoo.com>
Steps to Reproduce:
Create 2 companies > Create employee in 1st company > Enable both companies > Create public holidays company-wise> In company 1 create a public holiday for (13/11/2023) > In company 2 create public holidays (13/11/2023) and (29/11/2023).
Then switch to the one company (where the public holiday was created only for (13/11/2023))> Go to attendance > Configuration > Enable the count extra hours feature > Create attendance date (29/11/2023) for ex. 9 hours > Go to employee form > You may see the extra hour of "1 hour" > Because there is no public holiday on 29/11/2023.
Then enable both companies > Create attendance date (29/11/2023) for ex. 9 hours > Go to employee form > You may see the extra hours of "9 hours" > Because there is a public holiday in another company on 29/11/2023.
Bug Source:
commit 1407052 fixed the fact that public holidays are not taken into account when computing the overtime, but it doesn't cover the multi companies case.
Solution:
Verify that the public holiday company and the employee company are the same before applying the compute.
An optimization was also added to avoid searching for public holidays in db by filtering with the
employee company.
opw-3597287
closesodoo/odoo#146987
X-original-commit: 62494f5c7c80f2fafa56e397f2cd918e1a9e2648
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce the bug:
- Create two storable product “P1” & “P2”
- Create a purchase order:
- Add 10 quantity of “P1” & “P2”
- Confirm the PO
- Go to the delivery:
- Set the quantity of “P1” at 2 and “P2” at 0
- validate the delivery and create a backorder
- Go to the backorder:
- The quantity set for “P1” is 8 and for “P2” is 0
- Try to validate and create a backorder
Problem:
Nothing happens because the quantity of "P2" is 0, and the "picked"
field is set to True. However, the quantity should be 10, and the
"picked" field should be set to False when the backorder is created:
https://github.com/odoo/odoo/blob/17.0/addons/stock/models/stock_move.py#L1822-L1828
opw-3629848
closesodoo/odoo#147128
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Current behavior:
The pos_self_ordering_mode field was not interpreted as invisible when
no PoS existed. Because this is a required field you were not able to do
any changes in the settings if you had no PoS.
Steps to reproduce:
- Archive all PoS
- Go to Settings, and change any settings you want
- Save the settings
- You get an error "Invalid field 'pos_self_ordering_mode'"
opw-3649784
closesodoo/odoo#147126
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Fix a bug where quick-create of products from the expense form view
would not use the service detailed_type by default. Allowing bugs
when sale_stock module is installed as it would be considered
as a storable product
Also updates the demo data accordingly
task-3458826
closesodoo/odoo#147123
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
When setting the ordered quantity on a sale order
under the delivered quantity, if the product used is storable in stocks,
an error is raised.
This improves the error message so that it's more understandable when
this happens due to canceling an expense report (move)
or re-setting it to draft
task-3458826
Part-of: odoo/odoo#147123
This deals with a bug when an expense re-invoiced
with a 'sale_price' expense_policy and 'delivery' invoice_policy
Current bad behaviour:
- When re-invoicing another expense matching the first one's
price_unit and product the quantities aren't updated properly
- Furthermore, reversing the original move doesn't impact the sale order
- Resetting the expense sheet to draft neither
New correct behaviour:
- When re-invoicing another expense matching the first one's
they aren't grouped together on the same line, allowing to update
and reverse the lines independently
- Reversing the original move sets its corresponding sale order line
quantity and delivered quantity to 0
- Resetting the expense sheet to draft does the same
- Resetting the original move does the same
- Adds clarity to the sale_stock error message, so it's understandable
from the expense view
task-3458826
Part-of: odoo/odoo#147123
Current behavior:
When you only used the "Next order coupons" loyalty program, the "enter
code" button was not displayed.
Steps to reproduce:
- Install the pos_loyalty module
- Archive all the loyalty programs
- Create a loyalty program with "Next order coupons" as reward
- Open a PoS session
opw-3608894
closesodoo/odoo#147101
X-original-commit: 55ad2020e4b56a2ce525959f0c021b83198446bc
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Current behavior:
When grouping by warehouse in the sales report, the pos orders appeared
under the "None" warehouse group.
Steps to reproduce:
- Create a PoS order
- Validate the PoS order, and close the session
- Go to sale reporting, group by warehouse
- A group "None" appears, with the PoS order inside
opw-3540797
closesodoo/odoo#147100
X-original-commit: 132dd31e7e7a941ad375ada0be35dde05d0b3a43
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
- Create a "/test" page, publish it
- Set "/test" as homepage url directly on the website (in the settings)
- Go to that page
- Open the page properties and change its URL from /test to /else
From there, the website setting (`homepage_url` field) was still set to
/test and not /else.
It means that the first "published" menu would then be used to avoid
serving a 404 as homepage to your visitors.
It is a bit confusing and people probably just expect to change that
website setting too when changing the page URL.
We had some feedback about similar flows (that couldn't be reproduced or
where people weren't sure) where people ended up writting on the wrong
page or losing their content.
Maybe this will mitigate the issue.
Kind of related: task-3476840
closesodoo/odoo#147086
X-original-commit: 374a1b31f70a3209b1ae11db8e5886350579c7f9
Signed-off-by: Jérémy Kersten <jke@odoo.com>
To reproduce
============
- on studio > create new report from internal layout
- execute 2 columns command --> the second column will be under the first one
Problem
=======
the browser finds out that the `iframe` is small to keep two `col-lg-6` side by side.
Solution
========
use `col-6` instead, like in 17
opw-3585043
closesodoo/odoo#147074
X-original-commit: 246f42baf76b308210a2b03d46a6143ace4bb7cc
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Before this PR, the "can reconnect after late close event" test
was relying on the `nextTick` helper to check which bus events
were received when the device switches from online to offline.
This test was non deterministic since a tick might not be enough
to receive the related events: the bus service communicates with
a shared worker through the MessagePort API, the worker uses a
Websocket which dispatch events upon connection/reconnection.
This commit replaces the use of the `nextTick` helper by the
dedicated `waitForBusEvent` helper which resolves once the event
is received.
fixed runbot-45695
closesodoo/odoo#147068
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
If multiple questions are conditionally displayed if the user selects an answer
in another multi-choice question, that answer was added multiple times in the
list used to filter mandatory questions that have to be answered when displayed.
This is an issue because the answer was only removed once if the user changes
his choice resulting in a state where a mandatory question that is hidden stays
mandatory even though it is not displayed to the user.
How to reproduce:
- create a new survey with:
- Question1:
- multi-choice with one answer
- 2 answers (A, B)
- Question2:
- single line text box
- mandatory answer
- conditional display depending on answer B of Question1
- Question3:
- single line text box
- conditional display depending on answer B of Question1
- start the survey
- click on answer B then click on answer A
Current behavior:
- user is not able to submit the survey with answer A selected
Expected behavior:
- user should be able to submit the survey
Note:
The issue was already fixed from 17.0 in this [commit], but the test is
still adjusted to ensure that displaying/hiding multiple questions at once
depending on conditional triggers works as intended without preventing the user
to finalize the survey.
[commit]: https://github.com/odoo/odoo/commit/55fa52be8a80e6f7ee2a526db29c0d97c24ae8f6
task-3630079
closesodoo/odoo#147008
X-original-commit: f574ec49b730917e8e781a9b47895048a389d585
Signed-off-by: Florian Charlier (flch) <flch@odoo.com>
Co-authored-by: Salvo Rapisarda <sdrapisarda@gmail.com>
Co-authored-by: Damien Abeloos <abd@odoo.com>
If customer did not have address,email and telephone fields,
"False" would be send to Adyen resulting in these field
containing False values, which in some cases was falsely
triggering anti-fraud system.
task-3159378
closesodoo/odoo#146990
X-original-commit: 0de6864e32cff260393fde391250cff0fa6d9653
Signed-off-by: anko-odoo <anko@odoo.com>
Steps to reproduce the issue:
- In website edit mode, add newsletter block onto the page.
- In the options of the snippet, change the template to "form".
- Click on the "Display Thanks Button" checkbox.
- => Traceback.
In this commit [1], a button has been added to the options of the
"Newsletter Block" snippet to allow the user to display the "thanks"
button in edit mode to be able to edit it.
Later, in another commit [2], a new "Form" template was added to the
"Newsletter Block" snippet, but the "Display Thanks Button" option was
not adapted for it.
This commit adapts the "Display Thanks Button" option for the "Form"
template of the "Newsletter Block" snippet so that it displays the thank
you message on the page, and the user can also edit it.
[1]: https://github.com/odoo/odoo/commit/a9eae10af88a0aba88ce6d3e3f517926edf36c00
[2]: https://github.com/odoo/odoo/commit/bd6ef64f4c79b9c04dc8b85dc2daccb61d55cad0
task-3610063
closesodoo/odoo#146867
X-original-commit: ccf338c67219b10fe86b15012e143a84c886654f
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
The portal view of the sale order total is broken.
This issue was fixed in this commit 619e5e0dad but it was removed in this commit df8535fbd4
The changes that were removed have been re-added.
task-3646364
closesodoo/odoo#146806
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Using the animation option on an image can turn the image src from
relative to absolute.
It then makes our code crash in some cases (multi domain & cors
protected img). The previous commit makes sure to protect this case by
making the code more robust.
This commit is fixing one of the detected root cause (explained in
previous commit).
The fixed code was introduced with commit [1].
Since we can't guarantee our code has no other way to turn relative into
absolute url, neither that we won't introduce new code doing that, the
very small safety net from previous commit has to be keep as defensive
programming.
[1]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85closesodoo/odoo#146731
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The image mouseover animation, introduced with [1], can crash through
legit UI flows:
- Visit your website on domain 1 (you will need to access the same
website from another domain later):
1. On local: use http://localhost:8069/ and http://127.0.0.1:8069/
2. On runbot: use master-all and master in URL
3. On odoo.com: use xyz.odoo.com and xyz.com
- Drag & drop "Text - Image" snippet
- Double click on the image to replace it
- Upload any image
- Click on the image and set its "Animation" option to "On Hover"
- Save
- Outside edit mode, mouseover the image to see the animation
- Behind the scene, the img src is changed from /web/image/xyz to a
hardcoded base64 value to show the animation
- Now enter edit mode, the system will actually reset the src to the
original src (to replace the b64) but it will replace it by an
absolute link and not the initial relative link
- Edit the text below the image, BUT DON'T MOUSEOVER THE IMAGE
(otherwise the absolute url would be turned into b64)
- Save, again DON'T MOUSEOVER THE IMAGE
- Now go on your second domain to access the same page
Bug: Mouseover the image, a `Uncaught Promise > Failed to fetch` error
will be raised because of a CORS error.
Indeed, on http://localhost:8069/, simply doing this in your debug tool:
```js
fetch('http://127.0.0.1:8069/website/static/src/img/snippets_demo/s_image_text.jpg')
```
will throw the same error.
Note: we can't just modify the CSP rule(s) to allow that domain because
we have no way to know which domains are safe and really domains from
the same database:
- When you are on xx.odoo.com, there is no way to know that xx.com is
also your domain for the same website. At best it will be set in the
website domain but it's not always the case (often not the case in
mono website)
- When you are on xx.com, we have no way to know that xx.odoo.com is
also your domain for the same website. At best it will be set in the
ICP `web.base_url` but until that ICP is actually frozen, it will
change every time the admin logs in the database.
[1]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85
Part-of: odoo/odoo#146731