Because of 2917b38f28 which appeared in v9.0 but has not been adapted to the new API
afterwards, the early return was out of sync with what a search returns in new API
in v9.0: search returns a list, so must our early return
in v10.0: search returns a recordset, hence the fix
OPW 1878192
closes#26474
On a new DB with demo data, as Demo User:
- Create a partner
- Unlink the partner
An `AccessError` is raised.
The error is raised on `ir.property`, for the field
`property_product_pricelist`. An entry was indeed automatically created
at partner creation. However, a regular user is not allowed to delete an
`ir.property`.
The property can be safely deleted as SUPERUSER as long as the proper
unlink access rights have been tested beforehand.
opw-1870737
Before this commit, we had two different errors when data was
unavailable:
The first one is generated by Odoo: "No data to display, try to[...]"
The second one is generated by nvd3: "No Data Available".
We always want the same message.
So now, we always make some checks before rendering
the graph by calling _render.
This reverts commit 6e8f1fcc63.
Reverted commit broke more than it fixed.
What it fixed : Show partner info when partner is changed after the
movelines are created (very specific used case, could be considered to
be the wrong way to do things)
What it broke : dropshipping
Use case specifically for round globally, but the justifications hold anyway
Have a session with one tax, multiple partners, and returns of freight (negative amounts)
When validating a pos.session, the computation of amls was a bit out of logic,
Namely, we grouped tax lines by :
1. their tax id (correct)
2. their partner_id (not wrong but limited)
3. their balance > 0 (wrong)
The justification for point 2 and 3 is two fold:
- Ultimately, the order is level of granularity that really makes sense
It's the order that is paid and therefore that has both legal and business meaning
and on which the amounts are retrieved anyway
- On the order, we litterally make the sum of tax amounts of each line, aggregating
credit and debit under the same variable
It is only logic to do the same for grouping the taxes at validation time
This commit only corrects the behavior for the rounding method 'globally'
OPW 1865700
closes#26203
- Create 2 companies C1 and C2
- Assign User U1 in C1
- Assign the default Sales Team (`sales_team.team_sales_department`) to
C2
- Create an invoice with U1
An `AccessError` is raised because the user is not allowed to access the
default Sales Team.
We fall back on `sales_team.team_sales_department` only if the user has
read access.
opw-1876966
You:
- open a grouping in a list view
- check a line of this grouping
- open another grouping
=> all checkbox are unchecked
With this commit, 0982ceaa is improved so the selection is only reset
when the list has been reloaded.
opw-1865736
closes#26213
Since cce70fd4 the attachment menu is only displayed for form view.
But if in another view there is active_ids (eg. selecting record in a
list view), we will still make a query to ir.attachment without using
the result.
Without the code change, the added test would fail when doing a
search_read RPC call to ir.attachment model.
related to #26213
When creating and editing a new calendar.event record from the calendar
view, the start_datetime field does not prefill from the day that was
selected on the calendar.
Introduced in e08f999468
opw-1875276
- Create a BOM for Product P with the following component:
Product C, 5.0 units
- Make some stock for C:
2 units in location 1
3 units in location 2
- Create a MO for P, reserve.
When trying to produce an error arise:
> Cannot set the done quantity from this stock move, work directly with
> the move lines.
If the user tries to unlock the MO in order to set the done quantity on
the move lines, the same error will arise when trying to produce.
In the specific scope of the production, we set the quantity done on the
move line instead of directly on the move, to avoid this limitation.
opw-1871241
Co-authored-by: Arnold Moyaux <arm@odoo.com>
Regenerate all child translations based on the .pot
Remove the terms that are either equal to the parent, either equal to the
source term.
Remove empty translation files
If a user wants to scrap more quantity than he has in stock, we return
to him a confirmation wizard. This doesn't make sense when scrapping
consumables products, as there are no quants for these kind of products.
task 1864026
- Generating the overview for a project may have a high memory usage for
projects with a lot of tasks.
This is due to the usage of "mapped" which stores data in the cache.
To avoid this, we instead use "search_read".
- Set 'Product Price' accuracy to 5 places
- Create a PO for a product to a new supplier
- Enter price at 3.14561 / unit
Supplier info entry rounded to 3.15, while it should be 3.14561.
Closes#22253Fixes#22252
When the MO is done, the reserved quantity on stock move is equal to 0
and decoration-success, decoration-danger, decoration-muted are all set
on the class. That implies an uncertain result.
This commit clarify the situation by applying
- decoration-muted if the MO is done
- success, danger or none otherwise
Related to task: #1862299
- Instead of adding the "timesheet" statbutton on the invoice's
buttonbox, this inherit view is adding a new buttonbox which causes
conflict with the original buttonbox.
PO that can be linked to an invoice are filtered via a domain
restricting the partner. However when no partner is selected yet, the
domain was `('partner_id', 'child_of', False)` which, beside being horribly slow, was also useless as it returns ALL partners.
Only generate a meaningfull domain.
Recommended by GitHub's repository alerts.
We normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 9.0 that would be Debian 8
(jessie) and thus Pillow 2.6.1.
However Pillow versions before 3.3.2 and Jinja2 before 2.8.1 suffer
from a few issues that could lead to crashes of Odoo workers.
The bugfixes have been backported in the DEB packages for Pillow,
so users of Debian/Ubuntu LTS versions won't be affected if they are
keeping their systems updated.
However it's worth an exception to our rule for pip users.
Lucas Perais (lpe)