In Python 3, SETUP_FINALLY is used if the exception object is bound in
the except block — even if there is no finally block — in order to
unbind and cleanup the exception's binding as part of PEP 3110:
https://www.python.org/dev/peps/pep-3110/#semantic-changes
This allows both using exception objects in Python 3 and using
finally blocks in both version.
opw 1824211
Have ~50 records in a column,
Mark 49 of them as blocked (kanban_state field)
Mark 1 or 2 as done
Before this commit, the bar that showed the proportions of blocked objects was invisible
This was because the min-width of a bar was 10px, without max-width
Leaving the red bar to 95% or something, the green bar to 10px
All of this overflowing 100%
After this commit, we compute max-width and min-width to be able to fit everything
within the progress bar
OPW 1867464
closes#25962
Since 2054b59 if we created a record in a many2many relationship of an
onchange, we would also possibly erreneously return the NewId.
The logic of convert_to_onchange of _RelationalMulti doesn't send back
the ID field (if the ID is needed, it is part of the command, not the
update/create dictionary values of a command) and this commit does the
same for the code changed in 2054b59.
This commit also adds a test for this fix, and a test for the regression
corrected with cd2ccc4110 reported in #25969
fix for https://github.com/odoo/odoo/commit/2054b5928#commitcomment-29837226closes#25984
When invoicing a line with an account that has a tax, ensure that line has the same tax of accounts. This is required by DATEV and is common usage in Germany
Was task 35289
Was PR #25202
I. modification and extension of SKR03 account chart
========================================
* improvment and mapping of Odoo standard account types (usage of all
available account types and fixing of wrong mapping)
* fixing of reconcile setting on several accounts
* update of account chart (to SKR03 2017)
* fixing of account chart by ascending order of accounts for easier
maintenance in the future and probably easier preparation of accounting reports
* backport of new account tags from V11 for better reporting
* shorter tags
* introduction of new taxes for all theoretically possible tax cases
needed to declare the VAT
* automatic mapping of taxes to accounts to auto detect the right tax
by selection of income / expense account on invoice lines
* assignation of tax groups to taxes
* introduction of reconcile templates (to allow booking of cash discount
cases)
II. modification and extension of SKR04 account chart
=========================================
* improved mapping of Odoo standard account types (usage of all
available account types and fixing of wrong mapping)
* fixed reconcile settings for all accounts
* update of account chart (to latest SKR04 2017)
* better source code by ascending order of accounts. Finally it will be
easier to maintain the chart in the future and also it will be easier
to identify and group records to to develop missing or new accounting
reports.
* backport of new account tags from V11 for better reporting
* shorter tags
* assignation of tax groups to taxes
* introduction of further taxes to cover most possible tax
cases needed to declare the german VAT
* automatic mapping of taxes to accounts to auto detect the right tax
by selection of income / expense account on invoice lines
* introduction of reconcile templates for cash discount deduction on
payments or low payment variances.
Access a SO with the access token, without being logged
Before this commit, the images of the so lines were the no image placeholder
This was because the route of the image was so.line/product_image
Since the token applies on SO, and not on its lines, nothing simple would work
After this commit, we hide the image if the user is the public one
OPW 1868916
closes#25973
When validating a leaves request with a user which is
in group group_hr_holidays_manager(Leaves Manager) and
group_account_invoice (Accounting & Finance Billing), it raised an
access error because the function _validate_leave_request
tried to create an analytic line with a project_id.
Without the rule account_analytic_line_rule_billing_user added by this
commit: https://github.com/odoo/odoo/commit/81218a8, a user which was
in group group_hr_holidays_manager and group_account_invoice had the rights
to validate a leaves request.
opw:1866243
Without the call to `super`, with at least two level off expected
onchange return data (eg. `invoice_lines.name`) we have an error in
python2, python3 python implementation of OrderedDict and possibly other
python implementation.
So this worked most often (with python3 CPython C implementation of
OrderedDict) by chance.
closes#25960
With the portal user, go on /my/task/1
(obviously provided that this task doesn't belong to portal user)
Before this commit, there is a 500 error
After this commit, the exceptions are handled and throws a 403
OPW 1867795
closes#25951
Before this commit, the style of the value and text in some stat buttons were
broken.
The design of the stat button is to have a single value and a single text which
are stacked as follow:
[CSS] [Visually] [Example]
.o_stat_info +---------+ +------------+
.o_stat_value | | | |
.o_stat_text | value | | 10 |
| text | | Forecasted |
| | | |
+---------+ +------------+
However, some stat buttons use multiple values or texts. For example:
[CSS] [Visually] [Example]
.o_stat_info +-------------+ +------------+
.o_stat_value | | | |
.o_stat_info | value text | | 3 Hour(s) |
.o_stat_value | text | | Lost |
.o_stat_text | | | |
.o_stat_text +-------------+ +------------+
[CSS] [Visually] [Example]
.o_stat_info +---------------+ +---------------+
.o_stat_text | | | |
.o_stat_text | text value | | Min: 10.00 |
.o_stat_info | text value | | Max: 20.00 |
.o_stat_value | | | |
.o_stat_value +---------------+ +---------------+
The latter is works fine with block, which guarantees vertical alignment.
However, the former case has some alignment issues like this:
[Visually]
+------------+
| |
| 3 |
| Hour(s) |
| Lost |
| |
+------------+
This is due to the use of `display:block` for any `.o_stat_text` and `.o_stat_text`.
This commit fixes this issue, without affecting the other cases.
Task-ID 1841523
Courtesy of Juan José Scarafía, ADHOC
The quality of the Spanish (Argentina) translations is very poor.
Remove them all and will start from scratch, translating only when needed.
Let's install base_vat_autocomplete and base_address_extended
When creating a contact with a VAT number, the street was not
formated by the autocomplete in a correct way because the function checkVat all the time
returns the street with the following format: '%(street_name)s, %(street_number)s/%(street_number2)s'
and this function doesn't take the street format of the country into account.
So the function _split_street tried to split the street into street_name, street_number, street_number2 with the
street_format of the partner but the street was not well formated by checkVat.
opw:1867491
The message don't show the name of product.
Before the fix:
The message was: "It is not possible to reserve more products of than you have in stock."
After the fix:
The message is: "It is not possible to reserve more products of [0221] Product A than you have in stock."
opw:1868449
On a multi-company environment, as sequences are created with sudo,
if admin's company is different from the user creating the warehouse
one, then warehouse sequences are incorrectly assigned to the admin's
company
Steps to reproduce the bug:
1. Create a Vendor with these address settings
- Name: Vendor123
- Streer" Street:
- Housnumber: 123
>> DO NOT ADD A COUNTRY => by default street_format = street_number street_number2 street_name
2. Create a purchase order for Vendor123
3. print the RFQ
>> ADDRESS FORMAT "123 Street" => OK
4. Go to vendor123 and set "Netherlands" as a country
5. Print RFQ again
Bug:
>> The address was still in format "123 Street" => NOT OK
When changing the country on a partner, the field street must be recomputed
because the street_format depends on the country.
opw:1865677
Before this commit:
* Install module A that implements model M and field X.
* Create a new custom field Y whose reference model is not M, implemented in
any module other than A.
* Make this field either a one2many, related or compute field depending
on field X.
* Uninstall module A.
=> The registry crashes fatally, the only way to recover from this is to
log directly into the postgres database and manually eliminate the
infringing ir.model.fields record.
The reasons are multiple:
* When creating custom fields that are relational, char fields are used
to hold data like model name, field name, instead of properly storing
the related field, which would let postgres handle the unlinking
properly.
* Despite this, the ir.model.fields method _prepare_update tries to make
up for this by verifying that the ir.model.fields being unlinked during
an uninstallation are not needed elsewhere and drops them, however it
does so naively: It assumes that the "problematic" field will be defined
within the module's scope, i.e. its model reference will be a model
defined by the module being uninstalled, this isn't always the case.
This is solved by getting the dependants of each field by accessing the
model's field_triggers, if there are any triggers (i.e. dependants) then
we add them to a `failed_dependencies` list for later processing. The same
is done for field inverses (only in the case of a many2one).
After finding the failed_dependencies, a check is performed to see if the unlink is
being performed in the context of an uninstallation, in which case the failed
dependencies will be unlinked, otherwise an error will be shown to the user.
This commit is a "backport" + generalization of commit 4265026ee2
Task-ID: 1856263
The changes should not have been merged in stable.
Users installing the account module before 3754280a had a not null constraint
on the field company_id.
After updating the code, the field is still required but has no default value.
If a chart of account is installed after updating the code, it would fail.
opw-1867358
Due to this commit: https://github.com/odoo/odoo/commit/ab5fcb29650349fa641c6130bf6dcbdc1ec28a07
When confirming a PO with two lines having the same product,
the stock moves were not merged anymore in the putaway
(input to stock) picking.
Reason:
When confirming the PO, odoo creates first a receipt
(vendor to input) picking and its stock moves matching the PO line.
Then it applies the push rule on each move. Both putaway
(input to stock) moves are created by copying the receipt
(vendor to input) moves, but when the second is created,
odoo check if there's another move to merge sharing same
properties to merge into it. As purchase_line_id is now copied
in both cases, both putaway moves include a different
purchase_line_id and won't be merged together, since this field
is in _prepare_merge_moves_distinct_fields() on stock.move.
opw:1854387
`new_landed_cost_value` was added to `value` to recompute the
`price_unit` field. The issue is that when applying multiple landed
costs, `value` and `new_landed_cost_value` already contains the previous
landed costs, resulting in an erroneous `price_unit`.
This patch only adds `cost_to_add`, which is the current landed cost, to
`value`, which contains all the previous one.
To reproduce:
- Create a product FIFO / AUTOMATED
- Purchase 50 units@$2 and receive them (total value=$100)
- Add a landed cost of $100 on those 50 units and a landed cost of $50 on those 50 units
(total value = $100+$100+$50)
- Sell 15 units (the value on move out =$75 > $75/15 = $5 unit cost)
The standard_price on the product = $7 while I expect to have $5
opw-1867002
The value of the statinfo widget is rendered by the qweb after a t-esc.
Say if the python rounding returned 14.0000000001
(supposed to be a two digits precision number through the magic of floats)
then the statinfo widget would print it as-is.
We now format the value at assignation.
opw 1865426
Steps to reproduce the issue:
- change the demo user settings -> use Sales: User: All Documents only
- create a stockable product with dropship feature on and a supplier
- connect as the demo user
- create a sales order with this product
- confirm the order
- as the admin user, confirm the purchase order generated through dropship
- connect as the demo user
- open the confirmed SO
- add a line with this product
- save the SO
Bug:
An access rights error was raised.
opw:1866015
When editing a translation on the website, if the user copy/pastes directly in
the web editor, then the html formatting is also copied.
Since the translation matching takes the html code into account when matching
the translations, this breaks the pairing.
When trying to save, the backend function validating the new translation thus
fails and return a server error.
However nothing was done with this error, and the user just witnesses that
saving doesn't work (unless he opens the console to notice the rpc failure).
We now display an alert dialog that notifies which tranlation causes the error.
opw 1862784
Since af9d6b86a1 and
5a57c29ff2 , python3.7 can be used to run
Odoo. This commit ensures that python3.7 compatibles versions of gevent,
greenlet and lxml will be installed without breaking compatibility with
Debian Stretch packages versions when using the Debian packaged Python.
Closes#25841
Have two invoices
Make a bank statement with one line, which amount is:
Amount[Bank] < Amount[Inv1] + Amount[Inv2]
AND
Amount[Bank] > Amount[Inv1]
Click on on the reconcile button on the form view of the bank statement
On the reconciliation widget:
Click on the first invoice to fully reconcile it with the payment
Click on the second to partially reconcile it with the payment
Before this commit, there was no way to let the second invoice open
and partially reconciled.
The only possibility was to make a write-off
V10.0 allowed to to do such a flow
After this commit, this use case is dealt with again
OPW 1864689
closes#25721
In python 3.7, async is a reserved keyword.
Using it in a method signature produces a syntax error.
Replace by an argument async_load and catch the previous calls in a kw for
backward compatibility.
Log a warning on public methods.
The **kw can be removed in v12 and officially deprecate the 'async' parameter.
Fixes#25578Closes#25783
Multiple currencies in the same POS have never been
supported. However, before ac89783d2f it
was possible to load a POS with a currency different from the
company's currency through the sales journal.
This re-introduces that option by manually converting to the default
pricelist currency if it's different from the company currency.
The currency conversion implemented here is based on (and should be
identical to) _convert on res.currency.
opw-1863047
When trying to click on "Mark as Done" on a MO with raw materials in a category
with automated fifo valuation, it raised in some a case (in function called
"_prepare_account_move_line") a user error saying:
"The cost of the product P is currently equal to 0. Change the cost or the
configuration of your product to avoid an incorrect valuation"
This problem coming from the fact that in some cases, self.price_unit was
equal to 1.04166666666667e-06 instead of 0
opw:1862153, 1866692
Olivier Laurent