Before this commit:
* Install module A
* Edit a view from module A, add a custom field
* Uninstall module A
* Reinstall module A
* Try to access the module A's previously modified view
-> Can't access the view, or even sometimes the app at all.
Cause:
When uninstalling module A, the custom field added to module A's is
properly unlinked, however the custom/studio view is not unlinked, therefore
the view references a field that no longer exists, when accessing the
view it will obviously crash (sometimes the traceback is not even
displayed to the user!).
Solution:
Emulate an ondelete cascade for child views only when in uninstall mode.
Steps to reproduce the bug:
- Create 3 stockable products P1, P2, P3
- P1 is tracked by serial numbers
- Create a BOM for P3 with one P1 and one P2 as components
- Set the quantity on hand to 5 for P1 and P2
- Create a MO for P3, produce it and mark the MO as done
- On the MO in the sheet "Consumed product", the quantity_done for
P1 and P2 are equal to 1.0
- Change the tracking of P1 to "No tracking"
Bug:
- Check the sheet "Consumed product" on the MO and the quantity_done
was equal to 0.0 instead of 1.0
opw:1856340
This changes the order in which the data and the views are loaded.
Caused a problem in some fringe cases.
Install then uninstall project, playing around with discuss, when reinstalling project ,
system is trying to notify a partner and the weird order
in which the data and the views are loaded makes it bite the dust
opw:1861157
On an optimization done for not rendering each time the template, the possibility
of sending the template in the proper language when multiple recipients was lost.
This is being refactoring in master, but for this version, Odoo won't merge a
change in the behavior, although it's the correct one as in previous versions.
Extracted by pedrobaeza from https://gist.github.com/nim-odoo/8a9749037370343f05c7e6681324f576
(cherry picked from commit 386a936)
In some undertermined circumstances, a `KeyError` might appear in:
https://github.com/odoo/odoo/blob/f9737d79e77e9abf634c8eaa4b6ea331e2aa814d/odoo/models.py#L4898-L4904
Despite the lack of reproducible use case, it seems that this was
introduced from 59b010ac36. In the meantime, other
optimizations were introduced in the prefetching of related fields, and
it seems that the fix is not necessary anymore.
Running the same script than described in
https://github.com/odoo/odoo/issues/19536#issuecomment-333118947 , we
observe the following performances:
Before the fix:
```
On change with 10 lines (10 new, 0 existing) took 0.306
On change with 20 lines (10 new, 10 existing) took 0.221
On change with 30 lines (10 new, 20 existing) took 0.208
On change with 40 lines (10 new, 30 existing) took 0.271
On change with 50 lines (10 new, 40 existing) took 0.306
On change with 60 lines (10 new, 50 existing) took 0.319
On change with 70 lines (10 new, 60 existing) took 0.354
On change with 80 lines (10 new, 70 existing) took 0.382
On change with 90 lines (10 new, 80 existing) took 0.506
On change with 100 lines (10 new, 90 existing) took 0.503
```
After the fix:
```
On change with 10 lines (10 new, 0 existing) took 0.238
On change with 20 lines (10 new, 10 existing) took 0.259
On change with 30 lines (10 new, 20 existing) took 0.250
On change with 40 lines (10 new, 30 existing) took 0.233
On change with 50 lines (10 new, 40 existing) took 0.287
On change with 60 lines (10 new, 50 existing) took 0.325
On change with 70 lines (10 new, 60 existing) took 0.345
On change with 80 lines (10 new, 70 existing) took 0.451
On change with 90 lines (10 new, 80 existing) took 0.496
On change with 100 lines (10 new, 90 existing) took 0.423
```
The fix doesn't seem to be necessary anymore, so we go back to the
previous implementation of the computed field.
Closes#25448Fixes#19536
opw-1861468
- Activate the Sale option 'Tax-Included Prices'
- Create and print an invoice
=> the total is displayed on each line
- Activate the Sale option 'Sections on Sales Orders'
- Create and print an invoice
=> the total is NOT displayed on each line
The option 'Tax Display' only applies to SO, not to invoices. Moreover,
we make consistent the wording.
opw-1856623
Before this commit, it was not possible to add an amount to a new
bank statement. The input (.o_form_field_monetary) appeared as disabled.
This bug was due to this commit: @a1224f5ca
This rule should be only applied to .o_form_field_radio.
Closes#18887
Task ID: 35832
Make sure to test `None` instead of any falsy value. Indeed, when we
want to explicitly pass a `False` default value, `set_multi` might
select an incorrect default value.
This is for example the case of `_inverse_product_pricelist`, where
`default_for_country` might be `False` on purpose.
opw-1858271
Before, when we created a picking manually with MTO+buy products,
put a scheduled date in the future and did "mark as todo", the
date on the po was related to now instead of that schedule date.
The scheduled date of the picking was passed to the date_expected
of the move, but not to the date of the move, which was passed to
the date_planned of the created procurement. By passing the
date_expected instead of the date of the stock_move to the
date_planned of the procurement, the po will have dates in function
of the scheduled date of the picking.
Courtesy of chienandalu. Closes#25223
Have a printer in a pos.config that doesn't have a url set
Open the pos
Before this commit, there was a JS traceback, since we tried to call
string operation on undefined.
After this commit, we avoid the traceback with a behavior that *looks like* the v9.0's
i.e. we don't care if the url actually means something, we put a message in the console though
OPW 1858063
closes#25442
Backport of 5f105d144d from v11.0
Commit 45c5a07d89 deals with displaying on the aged balance reports
the lines that zero out each other: an invoice and a payment of the same amount for the same partner
However, that commit overlooked that when there is a chain of reconciliation
that puts the report line to zero, it was displayed as well.
This present commit corrects this by making sure there are amls that detail the report lines
OPW 1857860
closes#25421
Steps to reproduce the bug:
- Set a language on your user
- Change the date format in this language and set '%d/%m/%y' (two digit year)
- Open the calendar and select day or week view
Bug:
- The date displayed on the column headings has 'y' where it should have the year.
To check the right date format: http://fullcalendar.io/docs1/utilities/formatDate/
opw:185924
The fact the pos config name get was doing
`config.session_ids[0].state`
led to the prefetch of fields of all the session_ids of this config
on reading `config_id` for the session form
Therefore, if a pos config had 1000 sessions,
it was prefetching fields of 1000 sessions when you actually
wanted only one session to display in the form.
Among others, the `picking_count` field which is
not stored and quite heavy to compute
In term of time, it went from 1 minute to 1 second
to open the form view of one pos session.
Backport of bc84eb2035 to 10.0
Countries with several official languages often have multiple names for their
states. Allow to translate the state name for such countries.
Some monolingual countries but, yet, with a need of translation of the addresses
such as China or Germany can add the same flag in their respective l10n_* module
Closes#25340
Usecase to reproduce:
- Enable multiple languages and companies
- Set one language on the admin and another on the demo user.
- Create a product and a translation for its name (both languages)
- Create an inventory adjustement in a company A for this product
- Switch on demo user (inventory manager rights but in company B only)
- Create another inventory adjustement for company B
- Add the invenory line with the product and save
The Inventory Line multi-company rule raise an access error
because the system set product_name on the inventory_line that is
a related field. Since it changes the product name with its translation
it will update it on other inventory line that have this product. The
other inventory line is in company A and the user don't have access to
it thus the access error is raise.
This adds readonly on the product_name since it should not be update
with an inventory line.
opw-1855137
The code was actually alreadt made in this spirit, there was just as wrong call to the date_invoice field of the model instead of the local variable with the same name, which contained the right value.
Canceling the delivery order created for a "Make to order" product
cancels the related procurement.
But canceling the receipt order created for a "Buy" product" with reordering rule
didn't cancel the related procurement. In some cases, it can block the application
of the reordering rules.
Now the related procurement is canceled when the receipt order is canceled.
opw:1845345
The end time of a calendar event is constrained to never be before the start
of te event.
However when updating events, one path would first update the start of the event
before updating the end of the event.
So in case where (s_1, e_1) is updated by (s_2, e_2),
with respectively s_i < e_i,
if s2 > e1 then the update would violate the constraint and thus crash
the calendar update.
opw 1854394
When removing Odoo Debian package, the directory /var/lib/odoo is also
removed. This directory could contain important data like filestore or
custom modules.
With this commit, this directory is preserved on removal and deleted
when the purge command is issued with a Debian package manager.
Fixes#22138
The controller /event/<model("event.event"):event>/registration/confirm
was broken since the portal user cannot read event.registration objects.
In 9.0 this was not an issue as we browsed and sudoed the
event.registration, but since in 10.0 this line disapeared so did the
sudo which this commit reintroduces.
If we applied a link eg. on:
```
<span>hello <b>world</b></span>
```
The system actually gets the "label": hello worldworld because there is
3 nodes:
text node: hello
element node: `<b>world</b>`
text node: world
Also since "hello worldworld" is different than "hello world",
instead of just keeping existing nodes and adding the link, the system
would replace the selected range by:
`<span><a>hello worldworld</a></span>'
instead of:
`<span><a>hello </a><b><a>world</a></b></span>`
This commit ignores element nodes when creating a new link, since when
getting the label of the link from the selection, only the text nodes
insides the element nodes have any interest.
There was a second issue because if we had:
```
<i><a href="hello">world</a></i>!
```
and tried to put a link over "world!", the code would decide: "world" is
inside a link so we will just update that link.
Thus we would get:
```
<i><a href="hello">world!</a></i>!
```
instead of:
```
<i><a href="hello">world</a></i><a href="hello">!</a>
```
opw-1848351
closes#25187
Field 'name' (Label) on account_move_line isn't required. When
following the usual flows, it is automatically set by the system.
However, one can manually create move lines without specifying it.
When this occurs, the Sale/Purchase Journal can't be printed
anymore because it causes a crash.
OPW~1857663
Adrian Torres