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
Before this commit, there was a traceback when clicking on a button
that generates a button call action with type `'button'`.
This is due to the handler of such an action that assumes only a small
set of button actions. Each of those cases correctly sets the local
variable `def` to a deferred, so that the post-processing is correct
(i.e. it handles this variable as a deferred). However, this is wrong
with a different button call action, so that this variable is `undefined`
instead of a deferred.
This commit fixes the issue by ensuring that the variable `def` is always
a deferred. As a result, the post-processing can make the correct assumption
that this variable is a deferred.
Steps to reproduce:
- Install Google Drive Integration app
- Go to General Settings
- In the category "Google Drive", click on "Get Authorization Code"
(displayed as "Get Author...")
Task-ID 1861630
When there is no ACL for a model, the system emits a log with a sample
ACL entry that developers should consider adding. This proposed ACL
should be safe: a default read-only access for internal users
seems appropriate.
Closes#25919
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
Have a product with a partner A as a seller, without any description whatsoever
Do a vendor bill with partner A as the partner.
Add the product onto the lines
Before this commit, the description on the line was "False"
After this commit, we fallback onto the product name if no other reference is set
OPW 1865969
closes#25857
Since 160d6577, the translations must be unique on the source.
When calling insert_missing on a field, the final step is to set the correct
source on every translation to keep them synchronised.
In case the translation looked like:
id | lang | src | type | res_id | name
---------+-------+-----+-------+--------+------------------
42 | fr_FR | KGM | model | 2 | product.uom,name
43 | fr_FR | kg | model | 2 | product.uom,name
The final step will fail as violating the unicity constraint.
Remove duplicated translations before making the update.
It was chosen to keep the latest translation as it should be the most up to
date (e.g. after an import creating duplicated translations).
Add a non-regression test for previous change
opw-1864123
Closes#25787
Make an invoice with a line having a cashbasis tax
Make a payment at a future date compared to the invoice's date
Before this commit, the cashbasis move attempted to post many times
which could lead to errors when posting is forbidden
(in the case of the french localization)
After this commit, the cashbasis move is posted only once
OPW 1865179
closes#25832
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
If notification layout used to encapsulate message send by email is not
found simply send emails without layouting instead of skipping it. We
should not avoid information to be send.
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
Christophe Simonis