This error occurs when user import records having value in 'properties' column
which is of datatype, 'properties' and while trying to get attribute from
getattr to get value of converter it is getting default value None. That's why
this error is produced, 'NoneType' object is not callable.
Steps to reproduce:
1) Install 'CRM' module.
2) Open 'CRM' module and in it click on 'List' view.
3) Open any record and add value for field 'Add a property'.
4) Export that records.
5) Now click on 'Favourites' > 'Import records'.
6) Now click on 'UPLOAD FILE' button > upload that exported file.
7) Now click on 'TEST' button, error will be generated.
By applying this, user will be able to import record of datatype
'properties'.
Sentry-4128524668
closesodoo/odoo#126609
X-original-commit: b80d4294a000e748677a3a0c1849140bf46ddbe8
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Before this PR, long text in the activity description could create a horizontal scrollbar in the chatter.
Task-2721466
closesodoo/odoo#126607
X-original-commit: 0d087cd335bff3dcc04d54889f87f7b143e42b67
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Didier Debondt (did) <did@odoo.com>
Steps to reproduce
==================
- Go to Accounting > Vendor Bills
- Create a new record
- Click on the Auto-Complete field > Search more
- In the search bar, search for a reference
-> str is not a function
Cause of the issue
==================
The search filter is declared as such:
```xml
<
field name="name"
string="Reference"
filter_domain="['|', ('name','ilike',self), ('reference','=like',str(self)+'%')]"
/>
```
This domain is evaluated in javascript by basic python interpreter.
Going from 15 to 16, it has been rewritten. The str function isn't
present anymore in `py_builtin.js`.
Solution
========
Since this is the last remaining usage of this function and `self` is
already a string, we can simply replace `str(self)` by `self`
opw-3383708
closesodoo/odoo#126593
X-original-commit: 4485d1ca6d1dfe33f4fca6d2cc140296ce4058a5
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Before this commit, if a session be open more than one day, it's won't
be possible to close the session with a cash difference. The problem
is that when the `ConfirmPopup` be added to the popup the
`ClosePosPopup` will be destroyed, and by confirming the "Payments
Difference" popup you will get this error:
```
Error: Component is destroyed
at ORM.call (.../web/assets/debug/point_of_sale.pos_assets_backend.js:17590:35) (/web/static/src/core/utils/hooks.js:174)
at ClosePosPopup.closeSession (.../web/assets/debug/point_of_sale.assets.js:9443:49) (/point_of_sale/static/src/js/Popups/ClosePosPopup.js:124)
at ClosePosPopup.confirm (.../web/assets/debug/point_of_sale.assets.js:9363:22) (/point_of_sale/static/src/js/Popups/ClosePosPopup.js:44)
```
The solution is to use `keepBehind: true` to prevent closing the close
popup. I tested in other versions and it wasn't an issue in
previous versions.
opw-3368772
closesodoo/odoo#126606
X-original-commit: 8484d3f1a25033bd91414f0ce61f7192874b0bc0
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
The issue happens when we have a really small percentage of tasks with a certain state and it’s very difficult to filter them clicking on the respective color in the progress bar. To fix this issue there was defined a minimum of 5% for each color and make sure that in the end the sum of values is exactly 100%.
To solve this issue, it was necessary to set a minimum of 5% for the width for every non-empty bar, also it was defined a max-width of 100 - (# non-empty bars -1)*5 % because we also have to ensure the sum of 100% at the end.
How to reproduce:
1. Go to Project -> tasks -> create a huge number of tasks in the same project (you can do it using interactive shell)
2. Change one of these tasks to another state (eg: done)
OPW - 3299363
closesodoo/odoo#126569
X-original-commit: bb533d8431d9adeb57539f7730649eb933fec105
Signed-off-by: Matheus Leal Viana (malv) <malv@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Purpose: In order to increase visibility of the interviewer group,
it is moved from hidden group, to recruitment group.
Moreover, we grant the interviewer additional rights in order to manage
the application process properly and be able to execute following actions
• Send an interview
• Check interview results
• Add/delete/modify skills
• Create a meeting
In order to allow above mentioned actions on skills to the interviewer,
we grant them all the rights to the hr_applicant_skill.
In order to let the interviewer send the survey we grant them access to
the private addresses and now recruitment-interviewer implies
survey-officer group as well.
Additionally, for the security purposes, we make a change, so that
the survey officer is not able to read recruitment interview results
unless they are also an interviewer for a specific applicant.
task - 3179332
closesodoo/odoo#118897
Related: odoo/enterprise#40696
Related: odoo/upgrade#4624
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When we have a long course name or we update the font size to something
big (24 px) for example the course name and the progress bar will overflow
outside its container.
Steps to reproduce the error :
1- go to one of the courses and update it's name to make it a bit long
2- click on one of it's content and got website preview
3- you can see that the progress bar is outside the container
4- if not : click edit -> theme -> change font size to 24 px
5- You can see now clearly that there is overflow from the container
The origin of the problem was because the container has fixed height
equals 80px
opw-3191888
closesodoo/odoo#126460
X-original-commit: 8184374450f8e2b775a29ff05b3128c24579bbba
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
pos*: point_of_sale, pos_restaurant
When deleting an order, the restaurant override of the deletion function
in `point_of_sale` interferes with the logic in such a way that we end up
writing the order that needs to be deleted 2 times.
This is obviously not the expected bahaviour. In this PR we remove
the `override` from `pos_restaurant`, as it is no longer needed and
we also add a mechanism that ensures that orders cannot be duplicated.
closesodoo/odoo#126442
Task: 3383043
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Previously, when an order was paid for at the restaurant counter,
the self-orderer received no update that the order had
been paid for.
Now, if the customer self-order page is still open on their phone,
it will receive a notification via websocket that the order has been
paid for from the restaurant counter.The order will no longer be
editable.
In the event that they have already closed the self-order when paying
at the counter, the next time they return to this page. An RPC request
will be made with the access_token of the old order and the
states will be aligned.
closesodoo/odoo#125921
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This PR make add a last used date to the canned responses
in order to know whether they are still usefull or not.
part of task-3332872
closesodoo/odoo#125909
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
pos*: pos_loyalty, pos_restaurant, pos_sale,
pos_adyen, pos_six, pos_stripe
At the moment, the `pos` models don't have access to the `env` variable.
This makes using `env` inside a model rather awkward.
This PR makes it so all the pos models have access directly to `env`.
closesodoo/odoo#124320
Task: 3358456
Related: odoo/enterprise#42209
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
For each form action, existing fields can be defined. These existing
fields are references to objects in the ORM. It is possible to put a
domain on the field in order to filter the elements you want. For
example, the "Create an opportunity" action has a "Salesperson" field
that refers to users. This field filters the external users of the
company in order to have only the internal users. Unfortunately,
although this domain is present, it was not taken into account when
displaying the values for the field. This commit fixes this problem and
takes into account the defined domain.
Steps to reproduce the bug fixed by this commit:
- Have the website_crm module installed
- Put a form on a page of the website
- Set the form action to "Create an Opportunity"
- Add a new field
- Set the field type to "Salesperson"
=> The list of users displayed contains external users of the company.
task-3095745
closesodoo/odoo#121903
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
on this case:
1. Reorderning rule with company 1
and related product and product template is shared mean
no company selected and related product template
contain multiple bom with different company.
so using this line
bom = (product.variant_bom_ids or product.bom_ids)[:1]
from this : `product.bom_ids` as product is inherits
by template, it's tried to read all the bom of different
company and different variant too for same template.
and that will raise multi-company issue.
so I think that should be same company as related
stock rules company.
see : https://github.com/odoo/odoo/commit/6825c440d54e38ebee13a5c184aec1a40586de0d
this was generated during upgrade database.
closesodoo/odoo#125571
X-original-commit: 4edab52bdba2bb53345506a3d83f42bfdccfcd8a
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit ensures that the unsplash beacon calls home when an unsplash
image appears on a page.
To achieve this it patches the RPC call when the test URL contains the
test name as parameter. The patch cancels the actual beacon call to
avoid polluting data during the test, but marks the image as having had
its beacon message sent. The test then simply checks if this marker
appears on the image.
task-3360109
closesodoo/odoo#126522
X-original-commit: 1b0f25130b461e7b531548363c680200c7363e7f
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
If the user change a location type of the 'Production' from inventory locations
and installs the 'MRP' module, the traceback will appear.
Steps to produce:
- Install Stock module.
- Inventory > Configuration > Settings > enable the Storage Locations.
- Inventory > Configuration > Locations > Remove the filter 'Internal'.
- Open the 'Production' location and change the Location Type to 'View'.
- Now install the 'Manufacturing' module.
Error: A traceback appears: 'ParseError: while parsing
/home/odoo/src/odoo/saas-16.2/addons/mrp/data/mrp_data.xml:17, somewhere inside'
At the time of installing the MRP module, it will search for the production
location using the location type as the production here - https://github.com/odoo/odoo/blob/f65a9bffe2cbc03b2efc969dc205c9ba01ee9ab5/addons/mrp/models/stock_warehouse.py#L65
If the production location is not found it will raise an userError. In this
commit, the production location is created based on the company if not found. It
will lead to the above traceback.
sentry-4215564628
closesodoo/odoo#126514
X-original-commit: e8ce51dd0b5024820eee6d5e60a3a3017a0e36f6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Parth Solanki (paso) <paso@odoo.com>
The menus added in the server data which are used in mockServer did not
reflect a realistic menu configuration. This was brought to light when
trying to fix the addition of links to ir.ui.menu inside a spreadsheet.
See task 2821480
Related ENT pr: https://github.com/odoo/enterprise/pull/42885closesodoo/odoo#126497
X-original-commit: 128475e8c29f8493b01710342179a5c468897c61
Related: odoo/enterprise#43209
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
The label of a facet with type "comparison" did not have any
background color. We set it to be the same as for the label of a facet
of type "groupBy".
closesodoo/odoo#126496
X-original-commit: b0527528ee73b503ffbfef491b2389018c119376
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
The label of a facet of type "comparison" had the role "button" while
click on it has no effect. That role should be reserved for the label of
a facet that is associated with a domain (e.g. a facet of type "filter").
X-original-commit: 4c649abf491b32c218769b0bb1eba19881dedbb0
Part-of: odoo/odoo#126496
Steps to reproduce:
===================
- Go to Quality -> Quality Control -> Quality Points.
- Create new Quality point, using `Receipt` operation, control per operation.
- Go to Inventory -> Operations -> Receipt -> New
- Add whatever product with a quantity.
Issue:
======
The validate button is displayed even when the quality checks are not done.
Added back the `show_validate` condition as this field's compute is overridden
in `quality_control` to also check whether there are still quality checks to
perform.
closesodoo/odoo#126385
Task: 3376811
X-original-commit: d52e146da2980e1c144aa7a9d6c8082bf6bf7adb
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Since [this other commit], initializing the color picker could trigger a
traceback. The traceback was due to the fact that for users to be able
to drag/move the color picker as they wished across different frames, we
needed access to the document of all the frames on the page.
Unfortunately, if one of these frames was not of the same origin, a
traceback was displayed. This commit corrects how we collect documents
from frames on the page, by only taking those whose document we have the
right to see (which do not raise a cross origin error). I didn't succeed
to reproduce the bug locally, but I got it on the runbot with theme
Nursery / Kiddo by dropping the block banner on the page, the error
appears because the block contains a vimeo video. In fact, you just need
to have embedded content (youtube / vimeo / ... video for example) start
edit mode, click on the block containing the video and the error is
displayed.
[this other commit]: https://github.com/odoo/odoo/commit/63bf363d302fe9f93a824fa6f1ff3bbe21f98088
runbot-22573
closesodoo/odoo#126447
X-original-commit: b22c1d942374014e0d50e5429c3f89cc1ca18173
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Before this commit:
When importing `stock.quant` with two lines with the same product and
different counted quantities, only the last line is taken.
After this commit:
Each line creates a `stock.quant`, even if a similar Quant exists.
The records will be merged at a later time by `_merge_quants`.
Steps to reproduce:
1. Create a storable product
2. Go to Inventory > Operations > Inventory Adjustments
3. Create a file with two lines with the same product,
and different counted quantities
5. Favourites > Import Records & upload the file
OPW-3340017
closesodoo/odoo#126480
X-original-commit: 45f7368222ead5df600992c66f0da56b3a7e959a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walravens Mathieu (wama) <wama@odoo.com>
When parsing an email containing an xml attachment, the `email` python
module will decode the base64 attachment using the charset or ascii if
the charset is missing.
In some cases, the payload is in UTF-8 but the charset is omitted. This
results in replacement characters for the non ASCII characters.
The solution is to force the charset to UTF-8, since it is a superset of
ASCII that should not be a problem.
NB1: Omitting the charset for text/xml is not recommended. See the RFC
(section 6.4): https://www.ietf.org/rfc/rfc2376.txt
opw-3144519
closesodoo/odoo#126474
X-original-commit: e3a5b46c7b4f5030e165a6d943ec2275aea5d583
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Currently, it's not possible to check the 'Peppol Bis 3' option on the
journals of Italian companies, since Italy is not present in our mapping
`COUNTRY_EAS`.
The EAS for Italian companies may be the codice fiscal (code: 0210) or
the VAT number (code: 0211). See
https://peppol.agid.gov.it/en/news/expiration-validity-codes/
Use the VAT number by default, and add it in our mapping such that the
option now appears for Italian companies.
opw-3346572
closesodoo/odoo#126462
X-original-commit: 92784a0a230c7e93e3ed9fb215376cbbf5ba1362
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Adding base translation files for l10n_sa_edi as well as arabic translation
closesodoo/odoo#125610
X-original-commit: 52e96a5ca8a051d8a1a57e1606b4b1b9e810ba7f
Signed-off-by: Josse Colpaert <jco@odoo.com>
- kanban view progressbar based on status
- new first column 'New' with the welcome mail template
- create date column renamed to 'applied on' and moved to front
task 3346175
closesodoo/odoo#123293
Related: odoo/enterprise#42098
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This traceback raises when user not selected 'Employee' and only selecting
'Check In' and 'Check Out', while creating a new attendance.
To reproduce the issue:
1) Install hr_attendance
2) Open Attendance and create a new record
3) Give values to only 'Check In' and 'Check Out'
Error: "AttributeError: 'bool' object has no attribute 'upper'" appears.
On '_compute_worked_hours' method calendar variable is getting value from
employee_id and that calendar timezone is used to get timezone.
https://github.com/odoo/odoo/blob/937d207028ab9bc1d3d332dc6dfe25f0de045026/addons/hr_attendance/models/hr_attendance.py#L50-L60
Therefore in the above use case, when triggering the compute method,
because of 'calendar' is depending on 'employee_id' and when
employee is not selected, it will leads to the above traceback.
Sentry-4274226351
closesodoo/odoo#126465
X-original-commit: 31491e40d2505c03d76e6c802435ad1dafa71c52
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Latams need more fields for VAT and Odoo Milk broke
how these fields are displayed.
opw-3382698
closesodoo/odoo#126461
X-original-commit: 960d47ccc9db2ae69836a5f1ed7bff163b051a42
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Before, when instantiating the taxes for France in a Belgian
company through a French fiscal position (multi-vat),
a traceback would be shown because the cash based transition
account would not be retrieved in the correct way.
By checking the existing accounts (which
are created on the fly for multi-vat) instead of browsing the record
and also, by allowing no account at all, we avoid tracebacks and the
taxes get created.
closesodoo/odoo#126473
X-original-commit: 85f45e37c4ad9503dcc96c321d26504bce3de2c0
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
before this commit, The Kanban view for project tasks includes a subtask button,
a remaining hour timer, an activity button, and assignees in its lower section.
However, when the task has subtasks and timesheet entries, these buttons appear
in the Kanban view, causing the view to lose its structure somewhat.
This commit includes reducing the right margin of the activity button and
remaining hours to provide enough space for other elements in the kanban view.
Additionally, the Lock Icon for private tasks has been given a left margin to
separate it from the activity button
task-3289941
closesodoo/odoo#126446
X-original-commit: eff472e39642bb29e5d4615fcfe1255c00ffc5ef
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Issue:
In the portal view of the project AGR project has 11 Tasks on the list view
but when you click on it, inside there are 12 tasks, not 11
Cause:
The Kanban view of the project includes a button for task
count, which displays the total number of open tasks in the project.
It seems that the task count button displays the correct count because the form
view of the task includes a default filter for 'Open Tasks'.
The form view of the project-sharing feature does not have the default filter of
'Open Tasks'. As a result, the count displayed by the task count button in the
kanban view is different from the count displayed in the list and Kanban views.
Fix:
In this commit, a default filter is passed through the context to ensure that
the task count displayed by the task count button is the same as that displayed
in the list and Kanban views.
task-3289941
X-original-commit: 96304e9b237c06a5d0b459d304df3afbf7607f04
Part-of: odoo/odoo#126446
The code snippet removed by this commit had no useful effect, as
`selection.addRange(range)` a few line above triggers
`OdooEditor._onSelectionChange`, which repositions the toolbar
elsewhere.
The result was a "glitch": the toolbar would briefly be displayed over
the top left corner of the media before finally being displayed above
(or below) it.
This commit removes such undesirable effect.
task-3347942
closesodoo/odoo#126445
X-original-commit: f0272411f6cab059cc8bc2ceed37d9ce59ffe80c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
Before this commit the position of the arrow was incorrect when the
editor is inside an iframe.
For the calculation of `arrowLeftPos` we need the difference between
the selection rectangle border and the toolbar's left position.
While `correctedSelectionRect.right` is relative to the current iframe's
borders, `left` is relative to the top document's window, as it has been
offset with `parentContextRect.left`. We need both values to be relative
to the same referential in order to make this calculation make sense.
task-3347942
X-original-commit: 8bad3a3fb00d59498455205e8d286a38adaf1335
Part-of: odoo/odoo#126445
Before this commit, an error in the toolbar position happened when the
editor was inside an iframe and the iframe's window had scroll bars.
Steps to reproduce:
- go to the Market Automation app (enterprise edition)
- create new campaign
- add new activity
- create a new mail template by typing a name and selecting "create and
edit"
- select the "plain text" theme
- add a lot of content in order to have the scroll bars
- scroll down
- select something to display the toolbar
The `scrollX` and `scrollY` variables in `_positionToolbar` are ment to
correct the floating toolbar position in case the document in which the
toolbar is mounted has some scrolloffset.
As the floating toolbar is always mounted on the body of the top
document, this is the document to watch for scroll offsets, and not the
inner document when the editor is mounted inside an iframe.
task-3263463
X-original-commit: fb080218def7c47e7b96cf284d613fc03b8325f6
Part-of: odoo/odoo#126445
When a field had an error (required, wrong format etc), upon submission
of the form there would be a JS traceback preventing the page to work
anymore (the Donate button would spin forever).
This is because the code was not adapted to the Bootstrap 5 migration.
It seems like this code to update the config's content is not required
anymore, as without it the content is correctly updated through the
existing `.popover()` call a line above.
You can ensure that by simply omitting your email and send the form, it
will tell you that the email is required. Then just type "a" in the
email field and send again, it will tell you that the format is not
correct.
Somehow, it seems to also be the case in Odoo 15 in Bootstrap 4,
removing those line do not break that.
Some fixes were made at [1] and [2] about the same issue but somehow
people just fixed their own case, while grepping `.config.content` would
have easily found this one too.
[1]: https://github.com/odoo/odoo/commit/37546006940f99c8860e89997ed7a623abd5fa72
[2]: https://github.com/odoo/odoo/commit/0cff1dc2967cafeb8964ed0802c309d3bb7f7525
opw-3381196
closesodoo/odoo#126444
X-original-commit: 9e46ceea801d5044f5db4fee65d5980c64cfa23b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In case we use multi company and a user does not have an employee
in every company which is quite normal (mostly you are employed with
exactly one company), the calendar is skipping the provision of the
unusual days like public holidays or the working schedule.
To be able to access and see the calendar in such a case we fallback
to the company calendar and fixed a domain for the public holiday
retrieval whereas the public holidays are not assigned to an employee
but the company or the companies chosen to be displayed.
closesodoo/odoo#126420
X-original-commit: d80a3965b7356f9d6b1294cf428667a1057a272b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When processing the buttons in the header of the arch,
the listArchParser did not use the method on this.
This was a significant drawback when trying to extend
the behavior of the parser.
After this commit, the processing of the button goes
through the existing method on this, making it possible
to extend that behavior. Note that for the processing
of the other buttons in the arch, this modification has
already been done earlier.
task-3072937
closesodoo/odoo#126400
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
+ update PO and POT files
+ unify i18n and i18n_extra
+ rewrite traditional Chinese to simplified Chinese
closesodoo/odoo#126396
X-original-commit: 02c6c2bed691f263a383636c5209aba5c8c6cf57
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
The customer was having an issue where they would create an expense from an email with the wrong cost on the expense.
Then when they would try to change the price on the expense record it would seem find all the way up until the journal was posted.
Issue:
When creating an expense from an email the unit_amount is updated instead of the total_amount.
This would cause issues if you had an attachment because when you would attempt to change the amount through the front-end this unit_amount would never get updated because it was set and there was an attachment (line 265).
However, when you would create a journal entry from this expense, because it has the unit_amount != 0 it would provide the unit_amount instead of the total_amount.
Thus propogating the original number from the email even if it was updated between the time of posting and the creation of the expense from the email.
Solution:
Implement an inverse function on total_amount that will update the unit_amount to total_amount_company.
This will cause the unit_amount to stay up to date with the total_amount while also taking into account currency.
opw-3286372
closesodoo/odoo#126388
X-original-commit: c2588824edc732bea40b1a8f6e5248b3d318b361
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
In the website settings, one of the fields allows you to switch settings
from one website to another. Unfortunately, as soon as the user did this
the record was considered to have changed (dirty) and therefore required
a save when it wasn't necessary. The previous commit prevents the header
settings (like the website switcher) from dirtying the record. This was
really necessary because as soon as a user had several websites, it was
impossible for him to access certain settings on all these websites
(except the first one). As soon as the setting performed an action, a
save was required (because the record was dirty) and the user was
redirected to the settings again.
Steps to reproduce the issue before the previous commit:
Install website
Have multiple websites
Go to Settings > Website Settings
Change the website
=> The user is notified that the record has changed and needs to be
saved, which is not true. So far it's annoying but not critical, but if
the user continues:
Activate the "Extra step during checkout" option
Click on "Configure Form"
=> The Save/Discard dialog appears because the record is dirty.
Click on "Save"
=> The user is redirected to the settings page again and cannot access
the form configuration of the second website. (it is the same issue for
most of actions).
The previous commit fixes the issue and this commit adds a test to
ensure that the users are able to change settings of multiple websites.
task-3265100
closesodoo/odoo#126387
X-original-commit: bed37396839891da04126a71b3d6a6e5e56672b0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Mohit Beniwal