To reproduce:
1- Configure a 0.05 cash rounding modifying the tax amount
2- Create an invoice using this rounding, for 3€, with a 21% tax (configured with some tags related on tax repartition; a Belgian one for example). => This will create a 0.02 tax rounding move line, for a total tax amount of 0.63 + 0.02 = 0.65
3- Check the tax report => Only 0.63 appears
This is wrong and leads to inconsistencies with the tax closing (which will consider 0.65 because of the tax account used), or the generic tax report (which only considers tax_line_id field, not tag_ids). The tags should be copied from the line we intend to modify the tax amounts of.
OPW 2714411
closesodoo/odoo#83091
X-original-commit: e8e4b0fe3913aadb0c8e1f958b65a24543e6fd9d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
Followup to #82105: turns out we kind-of forgot that records could be
updated with new attachment and the exact same issue could occur.
So with the same reasoning as the previous PR, re-attach attachments
to the current object when updating it.
closesodoo/odoo#83083
X-original-commit: 398070ec1b6ed7d6a8e7c0ab75d45b8a9ad0e0d0
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In order to provide more transparency, we display any MOs linked to a
SOs via MTO linkage. This includes linkages made via reception report.
Part of Task: 2662730
closesodoo/odoo#79627
Signed-off-by: Arnold Moyaux <arm@odoo.com>
odoo/odoo/pull#79015 fixed some linkages for SO <-> MO, but removed the
linkage for backorders. This made a strange case where a (backorder) MO
could display a SO as being linked to it, but not the other way around.
Discovered during Task: 2662730
Part-of: odoo/odoo#79627
Allow use of reception report for MOs. Same behavior is expected as with
(non-outgoing) pickings. With exception that procurement group linkage
should be included when assigning.
Original Reception Report Task: 2500844
Follow Up Reception Report Task: 2632884
Task: 2662730
Part-of: odoo/odoo#79627
odoo/odoo#35551 removed the section the "byproducts" setting was in, but
the "o_settings_container" div wasn't removed at the same time. This is
mostly not noticeable, but it is annoying when adding new settings after
this setting since the layout will be messed up, so let's delete it now.
odoo/odoo#73939 switched the setting Lock by default => Unlock by
default, but forgot to update the setting title. Let's delete this title
as the setting is now self-explanatory.
Part-of: odoo/odoo#79627
In the next version of Owl, all exported terms are directly available
from the top level `owl` object. This commit aims to adapt existing
imports to this new system. This is done by importing any Owl property
used in files at the top, right after the `import` or `require`
statements.
closesodoo/odoo#82736
Related: odoo/enterprise#23609
Signed-off-by: Géry Debongnie <ged@odoo.com>
Purpose is to have one file per model for: python models, views, data.
Prepares Task-2245823
closesodoo/odoo#83070
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
This commit cleans the UTM module and uses a different file for each model
data and demo in order to clarify organization and ease reading. Each model
owns its own demo and data file. Security file is reorganized per model.
Task-2245823
Part-of: odoo/odoo#83070
Purpose
=======
This commit cleans the UTM module and uses a different file for each model
views in order to clarify organization and ease reading. Each model owns its
own view file.
Task-2245823
Part-of: odoo/odoo#83070
Purpose
=======
This commit cleans the UTM module and uses a different file for each model
in order to clarify organization and ease reading. Each model belongs to
its file.
Task-2245823
Part-of: odoo/odoo#83070
Current Behaviour:
- 'Create' button on hr.attendance.overtime is present but serve no purpose
Behaviour after PR:
- 'Create' button is hidden
'Create' in hr.attendance.overtime is present but has no effect because all the overtime are computed based on attendance.
opw-2730433
closesodoo/odoo#83068
X-original-commit: 7fea5ebcb58c79f93b688ccce90f1f506323414f
Signed-off-by: Kevin Baptiste <kba@odoo.com>
As the FEC can be downloaded by non-french companies, the length of a given vat number might be different than the french's vat.
Currently, if the vat length was lower than 13, it raised an error.
For french companies -> include the SIREN in the name of the FEC file (legal requirement)
For non french companies -> include the complete vat number in the FEC file
closesodoo/odoo#83054
X-original-commit: c3c05bf073a521a662d83c3382e77cb25c59bc3c
Signed-off-by: Laurent Smet <las@odoo.com>
When printing an invoice with tracked products, if there are several
invoices linked to the sale order, the displayed lots may be incorrect
To reproduce the issue:
(Need sale_management)
1. In Settings, enable "Display Lots & Serial Numbers on Invoices"
2. Create two products P01, P02:
- Storable
- Tracked by lot
3. Update their quantity (>1)
4. Create and confirm a SO with 1 x P01 and 1 x P02
5. Deliver the products one by one
6. From the SO, create an invoice INV01
7. On INV01, remove the line associated to P02
8. Post INV01
9. From the SO, create and post the second invoice INV02
10. Print one of the invoices
Error: [1] When printing INV01 (which only contains P01), the lot of P02
is also displayed. [2] When printing INV02 (which only contains P02),
the lot of PO02 is not displayed
When rendering an invoice, `_get_invoiced_lot_values` is called and
provides all data about invoiced lots. However, there are two issues:
- [1] it considers all related SML, even the ones related to a product
not present in the invoice
- [2] when computing the date of the last invoice, it uses the same date
for all products in the invoice although it could be different depending
on the product.
OPW-2637107
closesodoo/odoo#83047
X-original-commit: 9ffd4a9c5755af241a7acc98bc97c790dbb1b84d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Bug
===
Since cd8e0e9f46 the filter "no_share"
has been renamed to "filter_no_share", but the context key
"search_default_no_share" has not been updated in the other views.
closesodoo/odoo#83048
X-original-commit: 131b366e8d841fe7b8d2325941ea8518bcf998a7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In some cases, the module can patch an event but if it is deleted, some write will fails.
This fix prevent the following traceback:
```py
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1057, in __get__
value = env.cache.get(record, self)
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 889, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'calendar.event(30350266,).attendee_ids'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 886, in get
return field_cache[record._ids[0]]
KeyError: 30350266
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1057, in __get__
value = env.cache.get(record, self)
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 889, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'calendar.event(30350266,).show_as'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/addons/google_calendar/models/google_sync.py", line 43, in called_after
func(self.with_env(env), *args, **kwargs)
File "/home/odoo/src/odoo/15.0/addons/google_calendar/models/google_sync.py", line 234, in _google_patch
self.need_sync = False
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1217, in __set__
records.write({self.name: write_value})
File "/home/odoo/src/odoo/15.0/addons/google_calendar/models/calendar.py", line 55, in write
res = super(Meeting, self.with_context(dont_notify=notify_context)).write(values)
File "/home/odoo/src/odoo/15.0/addons/calendar/models/calendar_event.py", line 491, in write
previous_attendees = self.attendee_ids
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 3389, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 2603, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1083, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3276, in _fetch_field
self._read(fnames)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3346, in _read
self.check_access_rule('read')
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3553, in check_access_rule
invalid = self - self._filter_access_rules_python(operation)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 3608, in _filter_access_rules_python
return self.sudo().filtered_domain(dom or [])
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 5511, in filtered_domain
data = rec.mapped(key)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 5436, in mapped
recs = recs._fields[name].mapped(recs)
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1176, in mapped
self.__get__(first(remaining), type(remaining))
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1087, in __get__
raise MissingError("\n".join([
odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: calendar.event(30350266,), User: XXX)
```
X-original-commit: 2f0c9ca75de616da61e327259d03a8831b8e159b
Part-of: odoo/odoo#83040
Before this commit, the following traceback could be encountered when events were deleted:
```py
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/addons/google_calendar/models/google_sync.py", line 43, in called_after
func(self.with_env(env), *args, **kwargs)
File "/home/odoo/src/odoo/15.0/addons/google_calendar/models/google_sync.py", line 233, in _google_patch
self._google_error_handling(e)
File "/home/odoo/src/odoo/15.0/addons/google_calendar/models/google_sync.py", line 177, in _google_error_handling
start = self.start and self.start.strftime('%Y-%m-%d at %H:%M') or _("undefined time")
File "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1087, in __get__
raise MissingError("\n".join([
odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: calendar.event(28241777,), User: XXXX)
```
X-original-commit: e77cbc639032e7f58345942330102b37e7a55971
Part-of: odoo/odoo#83040
When an attendee is deleted in google, we need to sync the odoo attendees and delete the ones that do not exist anymore in google.
Unfortunately, by doing so, we introduced an issue. We filtered attendees that were no longer existing when we looped on the attendee emails.
```py
odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: calendar.attendee(YYY,), User: XXX)
```
This commit ensure that we filter only existing attendees.
X-original-commit: 0fb1002c9bb027d1694b834c52e4492a03c8a09d
Part-of: odoo/odoo#83040
In calendar events, the displayed colors are a bit dark and meeting
names in black don't have enough contrast. This commit fixes this
issue and improves general design of the calendar module.
task-2704288
closesodoo/odoo#81184
Signed-off-by: Arnaud Joset <arj@odoo.com>
It helps to debug queries executed in postgresql from Odoo
in order to know where they were called
Enabling the postgresql logs with the following `log_line_prefix`
log_line_prefix='%t [%p]: [%l-1] db=%d,user=%u,client=%h,app=%a '
You will see the following output in the postgresql.log:
... UTC [394452]: [371-1] db=odoo,user=odoo,client=127.0.0.1,app=odoo-740755 LOG: 00000: duration: 0.074 ms statement: SELECT 1
Notice `app=odoo-740755` it is the odoo pid that executed the query
and the postgresql PID `... UTC [394452]:`
Then you will be able to match the odoo.log and postgresql.log using the PIDs
740755 DEBUG odoo odoo.sql_db.connection: ConnectionPool(used=1/count=2/max=64) Create new connection backend PID 394452
740755 INFO odoo odoo.addons: Running SELECT 1
Notice the Odoo PID `740755 INFO` and the postgresql PID `backend pid 394452`
Note: It will require enable the sub-logger
- `--log-handler=odoo.sql_db.connection:DEBUG`
It will helps to debug what process is executing each query in the database
or if a postgressql PID is showing a error log related to connection (not even from a query)
e.g. The livechat stuck and you don't know what happen but you can see the postgresql.log the following message
for the same PostgreSQL backend_pid related to longpolling odoo pid
[394452]: [371-2] db=odoo,user=odoo,client=127.0.0.1,app=odoo-740755 LOG: XX00: Could not receive data from client: Connection time out
closesodoo/odoo#82857
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
When you are choosing to apply a down payment on a sale order in pos,
it'll add a line to the pos order with the down payment product and the
value you choosed.
In this case we are considering that the down payment product is set and
a traceback is triggered when you try to apply down payment.
So we are now handling this error when no down payment is configured.
closesodoo/odoo#83037
X-original-commit: a103a7f3c129cc1140b734f8f0be24cd4b8667b8
Signed-off-by: Masereel Pierre <pim@odoo.com>
When returning a kit, the margin of the related SO decreases
To reproduce the issue:
(Need sale_management)
1. In Settings, enable "Margins"
2. Create a Product Category PC:
- Costing Method: FIFO
3. Create two products P_kit, P_compo:
- Both:
- Type: Storable
- Category: PC
- P_compo:
- Cost: 10
4. Update P_compo quantity: 1
5. Create a BoM:
- Product: P_kit
- Type: Kit
- Components: 1 x P_compo
6. Update P_kit's cost
7. Create and confirm a SO with 1 x P_kit, unit price = $100
- Note that the margin is correct: $90
8. Process the related picking
9. Create a return R
10. Go back to the SO
Error: the margin is now $80
When computing the cost of the kit, the move linked to R are considered.
Therefore, the cost becomes $20 and thus the margin becomes $80
OPW-2679473
closesodoo/odoo#83008
X-original-commit: 2f34669f9dc3c9abfcbb13198f90f37405ffc258
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
In some cases, when making an inventory adjustment, the `in_date` of the
new quant will be incorrect
To reproduce the issue:
(Let D01 be the current date)
1. Create a storable product P
2. Set its quantity to 1
3. Process a delivery order with 1 x P
4. Set the date in the future
- Let D02 be this date
5. Make an inventory adjustment with 1 x P
Error: The `in_date` of the quant (for P in the stock location) is D01
instead of D02 (can be observed either directly in PSQL, on the form
view of the quant (via Locations > Current Stock), or by adding the
field on the tree view)
When validating the stock adjustment, at some point, the module calls
`_action_done` on a SML (1 x P from Inventory Adjustment to the Stock
Location). To do so, it decreases the quantity of the origin location
and increases the quantity of the destination location thanks to
`_update_available_quantity`:
https://github.com/odoo/odoo/blob/b4a9e5b8307ab1b730effe2de23f15260326ef6c/addons/stock/models/stock_move_line.py#L485-L493
But here is the issue: when decreasing the quantity in the virtual
location (Inventory Adjustment), it finds an old quant (the one from
step 2 in above use case). It then stores its `in_date` (D01) and since
this date is before the current one (D02), D01 is kept, used to update
the quant quantity and returned in `action_done`. As a result, when
increasing the quantity in the stock location,
`_update_available_quantity` is called with the parameter `in_date`
defined and equal to D01. Again, D01 will be the earliest date, so the
date will be used to create/update the quant in stock location.
OPW-2702198
closesodoo/odoo#83009
X-original-commit: e27ee5cd6b19351a00030310d1db3a0defe5b31a
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
The aim of this commit is to allow user to post a reversed entry even
when the date for the reversed has been set in the future.
before this commit:
if the move is generated using the reverse entry button and a date in
the future, the reverse entry is created with auto_post True and is
readonly in the view resulting in the user being unable to post the
move himself.
after this commit:
auto_post can be manually set to false and the user can post the move
himself.
closes odoo/odoo#83029
Task: #2522640
X-original-commit: 40b7976de1fe1cae71eb1063188eacb9a8a8fb70
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
steps to reproduce:
- install blog
- create more than 12 articles with at least on word (the one we will search for)
- Go to the "blog" menu of the website
- Go in the search field
- Search for the word in the created articles
-> Odoo removes the search criteria on the blog (Website) + number of results is inconsistent
OPW-2720355
closesodoo/odoo#83031
X-original-commit: bc2ed4a5f0997929930e3f279e5e1347818f8880
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The tool to change background color in mass mailing will currently
set the CSS property as !important.
On outlook software (or windows mail app) this seems to fail:
- !important on inline CSS should not be used
In this fix we remove !important when inlining CSS.
opw-2641343
note: this forward-port is only taking half of 14.0 d7e5101603 since the
issue of targetting DIV elements does not apply here (the <div/> with
the background color are transformed in table in convert_inline.js).
closesodoo/odoo#82924
X-original-commit: fb675251ce8b13d36dfac7a50e9b1cea4759cc02
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before when you installed one localization e.g. PE, but then you would
install another one with a demo company, then that demo company's demo invoices
might have adapted to the structure of PE, while it might be for another
country.
In the meantime we check that the necessary latam_document_numbers are set.
closesodoo/odoo#82998
X-original-commit: bef38eaee0e389554d35fede53a1224b72271d7f
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Prior to this commit the 'o_Activity_details' element was using a
discontinued bootstrap class, causing the layout to brake.
task#2731819.
closesodoo/odoo#82893
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When reversing an invoice linked to a sale order, the value of the new
anglo saxon AML should be based on the value of the returned product
To reproduce the issue:
(Need account_accountant,purchase)
1. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
2. Create a product P:
- Type: Storable
- Product Category: PC
3. For C in [10, 20, 30]:
- Create a purchase order with 1 x P at cost C
- Receive P
4. Create a SO with 3 x P
5. Deliver the products one by one
6. Create and Post the invoice INV linked to SO
7. Return the second delivery
8. Add a credit note to INV01:
- Credit Method: Partial Refund
9. Set the quantity to 1
10. Post the new invoice INV02
Error: The anglo saxon lines are listed in the journal items, which is
correct, but their value is $30 while it should be $20 (i.e., the value
of the returned product)
When delivering the last product, its standard price is updated with the
new value ($30):
https://github.com/odoo/odoo/blob/6b96ed418cb626678f4fa5baec25a903d7a74eda/addons/stock_account/models/product.py#L305-L307
Later on, when posting the credit note, the module gets the anglo saxon
unit price (`_stock_account_get_anglo_saxon_price_unit`). However, it
does not consider that the current account move line is reversing
another one. In the reversing process, the computation of the invoiced
quantity should be based on the invoices lines that are reversing too.
Moreover, when computing the average unit price of the returned product,
the module should use the stock moves that are returning the product.
In the use case, because of the two issued noted above,
`_compute_average_price` does not find any stock valuation layer to
compute the average unit price and uses the fallback, i.e. the standard
price of the product:
https://github.com/odoo/odoo/blob/6b96ed418cb626678f4fa5baec25a903d7a74eda/addons/stock_account/models/product.py#L652-L656
That's the reason why, in the above case, the value is $30 instead of
$20.
Note: a similar use case can be reproduced with a kit
OPW-2646926
OPW-2628215
closesodoo/odoo#82978
X-original-commit: 524d0d5e8817e1c7bcc99204c4cbb90fcfb6074c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When reversing an invoice that contains some anglo-saxo AML, the new
anglo-saxo AML should have the same unit price than the original one
To reproduce the issue:
(Need account_accountant,purchase)
1. Create a product category PC:
- Costing Method: AVCO
- Inventory Valuation: Automated
2. Create a product P:
- Type: Storable
- Product Category: PC
3. Create a purchase order PO01 with 2 x P for $10
4. Confirm PO01 and process the receipt
5. Create and Post an invoice INV01 with 2 x P
- As listed in the journal items, the anglo-saxo lines have been
generated with a value of $20
6. Create a purchase order PO02 with 2 x P for $20
- The cost of P becomes $15
7. Confirm PO02 and process the receipt
8. Add a credit note to INV01:
- Credit Method: Partial Refund
9. Set the quantity of P to 1
10. Post the new invoice INV02
Error: The anglo-saxo lines are listed in the journal items, which is
correct, but their value is $15 (the new cost of P) while it should be
$10
When reversing an invoice with the "partial refund" method, the
anglo-saxo lines are generated via the regular flow (as if it were a
"standard" invoice). Therefore, when getting the unit price of the line,
it uses the product's standard price. In such situation, it should use
the unit price of the original line.
OPW-2646926
OPW-2628215
X-original-commit: 87f7e78340dfe553923b2b65f61de06d5778cfbd
Part-of: odoo/odoo#82978
The letterRendering setting was only properly set for the `Printer` class but not for the `EpsonPrinter`.
closesodoo/odoo#82980
X-original-commit: 3bbf4bbcc0e1f81c1eddb91b54c3c863722aea46
Related: odoo/enterprise#23586
Signed-off-by: Masereel Pierre <pim@odoo.com>
If you have some text in your task, the second column will be stacked
closesodoo/odoo#82979
X-original-commit: 60f0d908386cf98a7879c9ad6788299d81d778cb
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Currently, when creating a new course from front-end, placeholder for
the course description is broken because it's split in multi line in
the xml file.
This commit fixes the issue by keeping the placeholder in a single
line in XML file and thus preventing the gap being displayed between
two sentences on front-end.
TaskID-2734524
closesodoo/odoo#82973
X-original-commit: 0db1844ddaf1f4cd46152e356dea10f3fd07169a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As this test is always red, notably because of the qunit asset bundle, the
threshold is raised for some bundles based on runbot builds
observations.
closesodoo/odoo#82972
X-original-commit: ab8350b5432a6a6d671bcc76413815274f7daaca
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Steps to reproduce:
Have a 0% Tax
Make an invoice with it
Open tax report
The 0% tax is not present in the report because there is no tax lines generated for them because the resulting balance is zero.
Since the tax details is making a mapping between tax lines and base lines and the tax report is using them to compute the report, the tax report is not able to compute the tax base amount for such taxes.
Explanation:
Until now, the tax line with a zero amount wasn't generated because considered as noisy journal items.
Now we must be able to groupby on the base tax account on the tax report, we are forced to use the tax details.
Injecting dynamically the 0% tax on the tax details sub-queries is really complicated and leads to a huge performance drop.
For that reason, we start to generate the tax lines for 0% tax even the balance is zero.
However, since there is nothing creating the missing lines in the past, it should be fixed case by case if needed.
opw-2711432
closesodoo/odoo#82971
X-original-commit: 65b5ec4ad65f798b1d647978b5b42a49e760139a
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Each delivery provider, requires some information about the packages
that need to be sent as well as about the commodities (for commecial
invoices). Since this is needed by each provider, and the required
values are very similar, these packages and commodities can be done one
step ahead: in the base delivery module.
These new `_get` functions return a list of custom objects containing
the most important values concerning packages and commodities, and can
be called directly from the child classes.
closesodoo/odoo#82891
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Steps :
- In mobile, go to Task
Issue :
- "Sales Order" stat button is not displayed.
Cause :
- This button's classe are :
- d-md-inline = displayed when size is medium+.
- d-none = or else not displayed
- In the past, there was a field SO in the form,
which made this button unnecessary and taking space.
Fix :
- Now that this field isn't present anymore, delete d-none part.
opw-2722535
closesodoo/odoo#82963
X-original-commit: 16f489ad6b6b9e8118bc806f220cf122e20374a8
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Some aggressive cache invalidation in the middle of method write() where
the model has children models (in the _inherits sense) causes very nasty
errors that are hard to fix.
Consider two models A and B, where B inherits from A. Also consider two
fields a1 and a2 on A, which are thus both inherited by B. Now take a
record from model B, and update both fields as:
record.write({'a1': ..., 'a2': ...})
As both fields appear as related fields on model B, the method write()
puts all values in cache, then it proceeds to call the inverse method of
both fields. The inverse method of a1 is called, and this writes on the
parent record. Now imagine that some override on A invalidates the
whole cache. When the inverse method of a2 is called, the field's value
on B has been invalidated, and this therefore writes the value False on
the record's parent.
This patch removes and adapt such cache invalidations:
- Since 4b1cb41cf7, the cache invalidation
in method write() of product.product is no longer necessary.
- The cache invalidation in method write() of product.pricelist.item
has been removed as well, since field that needs to be recomputed no
longer exists.
Fixes#76946, #77042closesodoo/odoo#82958
Opw: 2657461
X-original-commit: 5a73a8a3697c0f2685471efa252e5eb1af738e83
Signed-off-by: Raphael Collet <rco@odoo.com>
oco-odoo