Since [1] when the blog tags field option was refactored to use the m2m
widget, the list of existing tags is not cleaned up anymore.
This causes custom tags to remain in that list when they are removed.
This commit adapts the existing condition to exclude custom tags that
have been removed.
Steps to reproduce:
- edit blog
- create custom tag 'test'
- remove custom tag 'test'
- create custom tag 'test'
=> was detecting the tag as already existing
[1]: https://github.com/odoo/odoo/commit/4a603cd59c8a3f33d9515f28d99a0f68c381c5d2
task-2811746
X-original-commit: 7f58519b922264efb6b6180608fd5a461d30b9e8
Part-of: odoo/odoo#109479
Since [1] when the m2m widget was introduced, events that were neither
from the create input text nor the create button did remove the internal
value of the text that was entered in the create input text.
Because of this "Create" had no effect if the user hovered e.g. a
suggested blog tag on its way to pointing to the "Create" button.
This commit replaces this behaviour by restoring the text value of the
create input when the create button is used.
[1]: https://github.com/odoo/odoo/commit/be05ac7e2b8d866a72693b761f3bc8576d54e59e
task-2811746
X-original-commit: 59ecbb96db75a77cdcce11460cdbe8aa04438449
Part-of: odoo/odoo#109479
Since [1] adding a new tag on a blog does not refresh the tag list in
the options tab. That commit sorts the `methodsNames` alphabetically.
Previously, the unspecified order of the methods just happened to make
the add operation work.
After this commit the tag list is reset that happens during `setTags`
is prevented when a new tag is created.
If at a later stage a mechanism is created to allow specifying the
order of the `methodsNames`, it should be used instead of this dirty
ad-hoc way.
[1]: https://github.com/odoo/odoo/commit/a48a30f954afcb6ff3a59c4f32b05fd0c2cfcd2b
task-2811746
X-original-commit: e35e1128f5a569f386429b5e532d4b96e9348191
Part-of: odoo/odoo#109479
During the conversion to Owl of the base_import action, the fields
mapping for each column was made incorrect.
The fields are now properly sorted between the suggested, additional and
relational categories and the subfields are also correctly handled (no
more duplicates and correct labels).
closesodoo/odoo#109416
Signed-off-by: Luca Vitali <luvi@odoo.com>
Since d6a1aa63702132ffc59d2412c2a009912eba797a, a name get saved from the result of a pivot was
stored with an incorrect `deferred`. The value stored was not the
deferred, but the result of `new Deferred().resolve`, which is
undefined.
This revision fixes this issue by storing the correct deferred.
closesodoo/odoo#109472
X-original-commit: b3ad5ee64865dc7a3b84cae18cd37002f6d69a91
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
*: pos_hr_restaurant, pos_restaurant
In #108891 the navbar was extracted out of the Chrome and into its own
components, but when a temp screen is shown, an overlay is placed over
the navbar to prevent the user from using it to navigate away as this
can break some flows, and the overlay was not moved inside the navbar.
This caused the overlay to go over the entire Chrome which was not the
goal.
This commit moves the block-header overlay into the navbar (and adapts
some code to make the tempScreen state accessible inside the navbar).
closesodoo/odoo#109456
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit: Outlook Plugin wasn't able to get the opportunities of
contact. The problem was that the `crm_lead_get_by_partner_id` function
calls `_fetch_partner_leads` from the `CrmClient` instance, while it
doesn't have this function.
The solution is inherit the `MailPluginController` which contains this
function.
opw-3092995
closesodoo/odoo#109452
X-original-commit: 7013772d3b760cba0ba2fc1e4162ccfc260eba43
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
After 95b74f4 reworked the BE CoA, the accounts "140000-Bénéfice
reporté" and "141000-Perte reportée" are missing in the chart of account.
Tose accounts are part of the minimal legal accounts needed and are also used
in the Belgian Balance sheet in the section "14 - Bénéfice (Perte) reporté(e)".
opw-2871547
closesodoo/odoo#109425
X-original-commit: 790d6635e4db801afeff33ddd0d9fba5cde945da
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Before this commit, two visual errors were present on mobile:
- In the employee form view, the name and professions were
overlapping with the profile picture;
- In the employee kanban view, the presence logo and the
activity logo were misaligned
This commit also fixes some indentation errors.
closesodoo/odoo#109145
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The form view of project.task in project sharing is modified to be
similar to the classical form view of tasks (in backend). A
priorititization is added to the views of project.task for project
sharing used in the following modules:
- project
- sale_project
- hr_timesheet
- sale_timesheet
task-3119935
closesodoo/odoo#109067
Related: odoo/enterprise#35421
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since mid-15, when there are still products (partners) in db that are not loaded in PoS,
they are loaded from db when a user searches it from the PoS.
However, after the load of the last products (partners) in db, a flag is raised
so that no call will be done after that to the db to search for new products (partners).
The problem is that, if a new product (partner) is added to the db while the flag
is raised in an opened PoS config, the config will not make call to the db to
load these new products (partners).
This PR makes the loading of products (partners) by the user through a search
always enabled, so that a new product (partner) can be loaded into the PoS config.
closesodoo/odoo#108025
Task-id: 3092473
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Steps to reproduce
==================
- Install mrp_product_expiry
- Go to Inventory > Products > Lots/Serial Numbers
- Add the column "Expiration date"
- Remove the groupby if any
- Select 2 records, set an expiration date
- Confirm
- Select the same records, remove the expiration date
-> TypeError: value.setZone is not a function
Cause of the issue
==================
When entering the readonly mode after changing the date, the function
`formattedValue` is called. But `this.props.value` is equal to `""`.
`formatDateTime` only handles `DateTime | false`
The field is rendered from this template https://github.com/odoo/odoo/blob/1d8f6359bbf55983a9582282d12a187c67cdf509/addons/web/static/src/views/list/list_renderer.xml#L233-L236
When `canUseFormatter` returns true, formatDateTime is called with
false, coming from `record.data[fieldName]`
opw-3111869
closesodoo/odoo#109436
X-original-commit: 5b26a080ae28fab2a78e92a838472578591eef17
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Current behavior:
When a refund order is created, the amount is not rounded the same way
as the orginial order.
Steps to reproduce:
- Create a rouding method with 0.05 as rounding value, with the DOWN
rounding method
- Create an order with a product of price 1.98
- Validate the order, the price should be 1.95
- Create a refund order for the previous order
- Validate the refund order, the price should be -1.95 but it's -2.00
Solution:
Always act like the order has a positive amount, and apply the rounding
the normal way. Then apply the sign of the original order.
If the remaining amount has a different sign than the original total,
we should invert the rounding method to apply a rounding in the same
"direction" as the original order.
For example :
- Original order is -1.98
- Rounding is applied and the total is -2.00
- After the payment, the remaining is -1.98 - -2.00 = 0.02
- Wich will be rounded to 0.05 wich is not correct, it should be rounded
to 0.00. So we invert the rounding method to apply a rounding in the
same "direction" as the original order. If we don't do this the total
due would have been -1.95 instead of -2.00. And the change would have
been 0.05 instead of 0.00.
opw-3106656
closesodoo/odoo#109422
X-original-commit: c92074e8ec5b4a11fa90f08a16c859bb72234863
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Before this PR, all this localisation was written in slovak, but all the localisation have to be written in english and then translated back in the native language. This PR correct that.
closesodoo/odoo#109040
Task-id: 3119583
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Steps to reproduce:
- Install Expense module
- Activate analytic accounting in settings
- Create an analytic account X
- Create an expense with X as analytic
- Delete the analytic account X
- Go back to the expense created
Issue:
Cannot access the expense (error message).
Cause:
The analytic account is deleted but the analytics (Json field) on the
expense are not updated.
Solution:
When deleting an analytic account,
if used in an expense raise an error.
opw-3059908
closesodoo/odoo#109012
X-original-commit: 6c058e62812605f511220ec6cde06ebe77ae7edd
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Version 16.0 removed the price different account following this pull request #99411
This decision has been made because it was only used anymore by standard cost method and real time valuation.
We thought that standard was not a valid accounting method and we didn't want to maintain code for it.
But:
- Standard could be valid if you manualy complete the accounting entries
by yourself (e.g. employees/machines cost in mrp).
- It's also valid if you record the difference between standard price and
vendo price (price diff)
If you want to have an estimation of your cogs (benefits and loss) during an
accounting period. People just do a manual correction at the end but they have
a real time reporting on the situation.
It's a too big regression to be acceptable. We apologize and reintroduce it for
16.0 and future version.
This PR reintroduce the fields in purchase and the fix module in 16.0 is
not needed anymore.
closesodoo/odoo#108736
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To allow people from v16.0 to have the new module in EURO, we added the module l10n_hr_euro in stable, this PR modify the l10n_hr module to allow people to migrate without problem since l10n_hr_euro become l10n_hr in master.
Also the old module l10n_hr of the stable version will be added so that they can keep an history. But like the other, we renamed the module to facilitate the comprehension.
l10n_hr in stable become l10n_hr_kuna in master.
closesodoo/odoo#108511
Task-id: 3102242
Related: odoo/upgrade#4154
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Before this commit, in the form view, the date range picker field was
not updated correctly when switching pages.
How to reproduce:
- Go to a form view with a date range picker field
- Open the date range picker
- Close the date range picker
- Next page
- Open new date range picker
Before this commit:
The dates selected in the date range picker correspond to those on the
previous page.
After this commit:
The dates selected in the date range picker correspond to the current
page.
closesodoo/odoo#109423
X-original-commit: da5c4fb5a363158bcdef17f593ab8a556415a65d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- create a company A
- create a company B with French accounting
- Select A and B in the company selector, with B being the active company
At export, the A's unaffected earnings account can be used instead of B's.
closesodoo/odoo#109421
X-original-commit: 17a7390ad8cd0b09ccad609febc9ccb0bea1aa3a
Signed-off-by: Josse Colpaert <jco@odoo.com>
when the vat is not configured in the company and on printing the invoice, the traceback is raised.
this is due to the calling of method _format_dotted_vat_cl that excepts the vat value as input, when the method is called without a vat value, the traceback is thrown.
add an if condition to check there is a vat configured in the company and then the _format_dotted_vat_cl method is called only when there is a value in vat.
closesodoo/odoo#109133
X-original-commit: cadbe9e632c17efc0e68409df6fe8789f3f1dd14
Signed-off-by: Josse Colpaert <jco@odoo.com>
CoA: account types, tags for Cash Flow, account groups, define better default accounts, ...
Tax Report: changed the order, created some lines,... based on the infos to be given for the JPK export
Taxes: some tax scope
task-2713260
closesodoo/odoo#109409
X-original-commit: cd799a6bdf7ac6897ca9561342f6e39bea1dba25
Related: odoo/enterprise#35564
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Steps to reproduce:
- Go to the eCommerce app > eCOmmerce Categories.
- Select any categorie or try to create a new one.
Issue:
The box containing the fields it's not displayed properly.
Solution:
Added the class `clearfix` to the sheet component as it used to be in
previous versions.
opw-3080099
closesodoo/odoo#109408
X-original-commit: 4373cf2901b8db61592eba7cff2fae60ff68348a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When a user that doesn't have to right on "Multi company", efaktur will crash
when creating a new entry to e-Faktur.
This is due to a missing permission on the field "company".
This fix to set "company" to invisible when the user is not in the
base.group_multi_company group
opw-3052775
closesodoo/odoo#109082
X-original-commit: 3e389564601928737647472a36056246209d05b9
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
On first focus in an autocomplete field, the text content of the input element
is automatically highlighted.
closesodoo/odoo#109025
Task-id: 3117420
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The press of the SO button in the ProductScreen of a PoS config returns an error when pressing it.
The fix changes the import made to PosContext and the use of this import
in the SaleOrderManagementScreen.js file so that the press of the SO button works as it should.
closesodoo/odoo#108923
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit the name assigned for the res_partner_menu_config menu from
contacts and crm module is the same. Thus we remove the writing of same name
again from crm module. Moreover this allows easier update of the
name.
closesodoo/odoo#109307
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit:
If the PoS config have no "Barcode Nomenclature" set, the PoS
session can't start and a cryptic JS traceback will be shown:
```js
TypeError: Cannot read properties of undefined (reading 'message')
at Chrome.start
```
This happen as the barcode rejected Promise request doesn't contains
an error message. More details in:
https://github.com/odoo/odoo/pull/108797
After this commit:
A more user friendly error is displayed
Note: the issue does not happen in previous Odoo's versions
as the field was required before.
opw-3110204
closesodoo/odoo#109191
X-original-commit: fae1f0e363587ac743cac2a7102528f1db4ec83b
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Currently, when a company is in a mono-currency environment, they can't
display the total amount in currency when looking at invoices, payments,
vendor bills...
This could be a problem in a situation where the company currency is,
for example dollars; at one point in time, transactions were made in both
dollars and euros and now only the dollar currency is activated. The user
wouldn't be able to differentiate between those transactions anymore.
task-3097112
closesodoo/odoo#107717
Signed-off-by: Laurent Smet <las@odoo.com>
Current behaviour:
When sending an email with an inlined image to an alias of a project,
the image is broken in the task description.
Expected behaviour:
The image should be rendered correctly.
Steps to reproduce:
- Install Project
- In Settings add a custom email server and set a domain alias
- Create a new Project and in it's settings create an email alias
- Send an email with an *inlined* image. (not attachment)\
- Image is not rendered correctly in the newly created task.
Reason for the problem:
Email with an embedded/inlined images are multipart, one is containing
the base64 encoded image and has a `content-id`, another one is the
html body that has an `<img/>` which source is a `cid` that references
the `content-id` of the encoded image. When parsing the email when
creating the task, we only take into account the `html` part of the email,
which becomes the `message.body` which is used to fill in the description.
Therefor we have an `<img src="cid:..."/>` that references nothing.
Fix:
Use the already parsed and sanitized `message.body` from the message's thread,
which converts the `content-ids` into relative links to web images.
We fill with that the description's body.
Affected versions:
- saas-15.2
- saas-15.3
- 16.0
- master
opw-3062444
closesodoo/odoo#109354
X-original-commit: 3c805400045f2ccc8ad4228eb5718af0e22a8027
Related: odoo/enterprise#35543
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
When a project is shared as editable and the url keeps the access token,
it causes a traceback when a task is open. This is due to owl trying to
evaluate a the access token value as a string.
This commit fix it by wrapping the value so the owl component can
evaluate it and get the access token value as a value and not as a
string.
task-3073965
closesodoo/odoo#109351
X-original-commit: 865a45bd170ad15a10b3a3572471f4bf6b5648e4
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
- install "contacts" and "sale_management" module;
- create a company contact with a value for "Industry" (Sales & Purchase tab);
- create an employee who works in this company;
- create two orders (one with the company and one with the employee);
- go to sales reporting tab and select the pivot view;
- filter by "Customer Industry" and then by "Customer";
Issue:
The employee is not placed in the right category of industry. He should be in the same category as the company he works in.
Cause:
When creating a contact, the `industry_id` field is not passed from parent to children.
(Moreover, this field being invisible for an "individual" contact, it is not possible to give it a value without using the studio application.)
Solution:
Add `industry_id` to `_commercial_fields`.
opw-3085032
closesodoo/odoo#109313
X-original-commit: 60962062aefd34c911385f671c56b03836b3025a
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
When editing a website form, a `search_read` request is fired on
`ir.model` model to get the list of possible form actions (create
ticket, create opportunity, etc.).
But since commit [1] in Odoo 15, non-admin users don't have read access
anymore on this model, leading to a traceback when clicking on a form in
edit mode.
Steps to reproduce (as designer):
- Install only website and login as admin
- Make "portal" user an internal user and give him "Editor and Designer"
rights
- Login as "portal" user
- Enter edit mode on any page and drag & drop the form snippet, or
simply go to /contactus page which already has one
- Click on the form -> Traceback
Steps to reproduce (as publisher/restricted editor):
- Install website_hr_recruitment
- Make "portal" user an internal user and give him the following rights:
- Website: Restricted Editor
- Recruitment: Administrator
- Login as "portal" user
- Go to a job page like /jobs/detail/experienced-developer-4
- Enter edit mode and drag & drop the form snippet
- It will crash
[1]: https://github.com/odoo/odoo/commit/5dc4cff60a557e14b08440c227423291c407899b
opw-3098097
opw-3101884
closesodoo/odoo#109339
X-original-commit: 054c216e93b818794316bfd4b8ce56d6853a61d3
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- Create 2 projects: 'Project1' and 'Project2'
- Enable sub-tasks
- In Project1 create a task, name it '1'.
- In task 1 add a subtask, name it '1:1'.
- In task 1:1 add another subtask, name it '1:1:1'.
- Go to Timesheet app > add lines for each task.
- The lines display name are "Project1 / 1", ...
- Go back to task 1, edit the task project to Project2 and save.
- The subtasks will have their project_id also set to Project2.
- Go to Timesheet app.
Issue:
Tasks 1 and 1:1 will have their display names updated to "Project2 / 1"
and "Project2 / 1:1". However, task 1:1:1 is displayed as
"Project1 / 1:1:1", meaning it's project_id was never updated.
This happens because of the way changed fields propagate to immediate
children, but not to grandchildren, which is intended behaviour.
Solution:
`_compute_project_id` is also called onchange, meaning that we can use it
to update account lines with an outdated project value with the new value.
opw-3018301
closesodoo/odoo#109352
X-original-commit: 91b42c806ce2029d9ef678d145ced3138e35bec0
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Expenses paid by company are marked as paid but the related journal
entry is not paid and cannot be paid
Steps to reproduce:
1. Install Expenses and Accounting
2. Create an expense payable to company and set an amount
3. Create report
4. Submit report
5. Approve report
6. Post journal entries
7. Open the related journal entry
8. Attempt to register payment: an error is raised
Solution:
Mark the journal entries created for the expense as paid if the expense
is paid by the company
opw-3075818
closesodoo/odoo#109375
X-original-commit: f5dd4e3326a17c1f6d06630503d1ede8cc6c59fe
Signed-off-by: William André (wan) <wan@odoo.com>
Cannot be used in v16 since some mixin don't exist anymore.
After 4 odoo versions, and now that we use bootstrap 5, we drop the
support of bs3.
closesodoo/odoo#109359
X-original-commit: 2c34fd4f031b006451305c46b99a790540c5e902
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
When creating a new lot in an inventory adjustment, the removal date,
the best before date and the alert date are not always defined.
To reproduce the issue:
1. Create a product P
- Type: Storable
- Tracking: By Lots
- Expiration Date: True
- Expiration Time: 2
- Best Before Time: 0
- Removal Time: 0
- Alert Time: 0
2. Update the on hand quantity of P:
- 1 x P with lot L01
3. Open L01
Error: Only the expiration date is defined. The other dates
(removal, best before and alert) should be defined too.
Considering the definition of the fields set on step 1:
https://github.com/odoo/odoo/blob/221ee0cdc362e1958f9a5326c1966de9dfb47c48/addons/product_expiry/models/product_product.py#L23-L35
The times defined on Best Before, Removal and Alert are the number of
days before the Expiration Date. So, if for instance the user
defines the best before time to 0, it means that the best before
date must be the same as the expiration date.
OPW-3072000
closesodoo/odoo#109353
X-original-commit: 8b06046379e6cfa62bd5b2df261a7ab22d5e2c3b
Signed-off-by: Adrien Widart <awt@odoo.com>
*: l10n_fr_fec, l10n_account_edi_ubl_cii_tests
Fix two failing tests in: - l10n_fr_fec: Add missing factor_percent in
the creation of a tax in the test for FEC - account_edi_ubl_cii: The
invoice name supposed the old convention per month while this was
changed to on a per year basis anyways for customer invoices.
These two tests were ignored by runbot for a while and began to fail
only after the runbot exception was removed (see:
https://runbot.odoo.com/runbot/build/22172258).
In addition, tests in `TestItEdi` started to fail as well when the
exception was removed ! In particular, if an exception was raised in the
`setUpClass` of `TestAccountFrFec`, the tests in `TestItEdi` were
failing.
This is because `TestAccountFrFec` is decorated with
`freeze_time('2021-05-02')`. Indeed, when one decorates a subclass of
`unittest.TestCase` with freeze_time, if the `setUpClass` raises an
Exception, `_freeze_time.stop()` is not called, and the frozen date is
propagated in the other test classes. As a consequence, when an
exception was raised in the `setUpClass` of `TestAccountFrFec`, the
freeze_time set in `TestAccountFrFec` (2021-05-02) was kept in
`TestItEdi`, thus causing tests to fail in `TestItEdi`.
As a conclusion, `freeze_time` should never decorate an Odoo test class.
closesodoo/odoo#109324
X-original-commit: 531270666ec5a6582d4a0a68ea534f2a3a6852ff
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Current behavior:
When creating a PoS config, it is possible to have multiple cash payment
method. Wich is not supported by the PoS.
opw-3030125
closesodoo/odoo#109331
X-original-commit: 7ba362b60a38a993fdeec920e6c90a754ddeb910
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Before this commit, trying to delete a page from the page manager in
debug mode would throw an error of type "Got duplicate key in
t-foreach".
As explained in this commit [1] and as per the [owl documentation]:
"Owl requires the presence of a t-key directive, to be able to properly
reconcile renderings." and "A key should be a unique number or string."
In our case, "dependency_value" is an array. Due to that, the current
item of the "t-foreach" iteration is the current value. The bug is
fixed by ensuring that the value of "t-key" is the current value index
and not the value itself.
[1]: https://github.com/odoo/odoo/commit/0d1c263298ca6724a6fe6c31e2a2d3221c5e8c75
[owl documentation]: https://github.com/odoo/owl/blob/master/doc/reference/templates.md#loops
task-3082345
opw-3100483
opw-3111671
closesodoo/odoo#109329
X-original-commit: f56d5906f845cb45f88d9729b73aa2ed08c551f3
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Install the "Surveys" application.
- Go to the "Website" application.
- Go in the page manager ("Site" > "Pages").
- Select a page (typically "Home").
- Try to delete it.
- Error of type "'survey.survey' object has no attributes 'name'".
The error comes from the fact that records do not necessarily have the
attribute called "name". To fix this error, this commit uses
"display_name" that is defined in all models.
task-3082345
opw-3100483
opw-3111671
X-original-commit: d5aa5d7ebf9cd17a6df054252a1313ec8b85e83e
Part-of: odoo/odoo#109329
Usecase to reproduce:
- Create a product with replenish on order route
- Create a SO for this product and add a shipping method
- Confirm the SO
The shipping method is not on the product.
It's due to the MTO delivery rule that miss the propagation of carrier
option. It's not set by default while it's is on the classic delivery
rule on the warehouse.
To avoid confusion we add it by default on both rules
opw-3112455
opw-3113180
closesodoo/odoo#109328
X-original-commit: c02df957d9f04c911f330aaaadd80fe97a601509
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Install stock
- Activate storage locations
- Switch to French language
- Go to stock/analyse/emplacements
- Select all locations
A javascript traceback pops up because the names 'Set' and 'Count Sheet'
are not translated, therefore we use _t function to translate the terms.
opw-3113275
closesodoo/odoo#109261
X-original-commit: 719a6e6223bbde3cdeb0ade5665d95681c436521
Signed-off-by: Tiffany Chang <tic@odoo.com>
This commit adds checks in the view validation, to detect the use
of implementation details in archs. The goal is to prevent people
from using owl directives in archs (e.g. t-on-click). Recall that
a view arch isn't an owl template, it must follow the DSL of the
given view type.
In kanban, gantt and activity archs, using `t-xxx` attributes is
forbidden, except for directives historically supported by qweb
(e.g. `t-esc`).
In other views, using `t-xxx` attributes is forbidden (except for
`t-translation`).
In all views, using attributes `data-tooltip`, `data-tooltip-template`
and `data-tooltip-info` is forbidden.
Task 3085357
closesodoo/odoo#107083
Related: odoo/enterprise#35352
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- create a cash rounding
- create an invoice
- in Other Infos, select the created Cash Rounding Method
Issue:
Accounting wise, everything works fine but the back-end view and the Invoice Reports do not take into account the rounding
(except wen you create a partial payment, the amount due is correct of course)
Solution:
Make sure the value `formatted_amount_total_rounded` is returned by the method `_prepare_tax_totals` so it can be used in the templates
opw-3090556
closesodoo/odoo#109312
X-original-commit: 5724858a374c894bf787b4381bdcd466b4cc2816
Signed-off-by: William André (wan) <wan@odoo.com>
Benoit Socias