Two account had the same account code. Because of that, one of them always failed to be created and logged a psql error. To fix that, we totally remove this account, as it never got created anyway.
Upon module upgrade, automatic fields are removed from `ir.model.fields`. This
is because those fields do not belong to the module of their model. Fix the
condition to update their XML id when the module of their model is upgraded.
Before this commit, if you use this field outside of a controller website,
it will fail because this field depend of request.website that is only set
on controller of type website.
Now we return False if we call try to use this field outside of the website.
Eg: call get_current_pricelist in json
The goal here is to keep the default behaviour of test-enable and test-tags
except that test-tags will set test-enable to true if set.
- +standart must stay the default test-tags if none are set
(only usefull if test-enable is set)
- should work no matter the order of "test-tags" and "test-enable"
options in args
- knowing the fact that for strange reason, _parse_config is called twice
PR: #27255
Before this rev. the lazy loading of views was correctly handled if there was
only one action in the action stack (which is usually the case when performing a
F5, the main use case of the view lazy loading).
Nevertheless, it might happen that the lazy-loading is used in top of other
actions (when performing a `doAction` with a form view for an action with
another view as first view, i.e. when leaving Studio while editing the form view).
The controller was `unshift` in the case (put in the first position of the
controller stack), which is not correct.
This causes the breadcrumb to be misordered and a traceback occured when trying
to access a breadcrumb element.
Co-authored-by: Aaron Bohy <aab@odoo.com>
Calling `html_container` is not only useless when using the `basic_layout`
but it's also dangerous because it is already present in the latter.
The assets will be added twice in the report (once in the head and once in
the body).
Morever, the <base> tag was added in the report ; this tag is only useful when
rendering the pdf version, which uses minimal_layout that already set the
<base> tag ; this tag can only be present once in an HTML document so it has
been removed from the BOM report.
This results in a report not being editable by Studio.
Reason: Following feedback from FP and AVW.
- Fixed the "split PDF" feature, it is now possible to leave an
empty page input, check the "split all" box and get a result.
Task: 1888982
Fine-tuning of commit:
b3a3ad8099ac1e187eea
The environment should be updated before the call to _updateAttachments,
as it depends on the env active_id.
opw 1888651
closesodoo/odoo#27277
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
With this commit, any *explicitly* related fields will be `readonly=True`
by default.
*Implicitly* related fields (i.e. _inherits fields) however will keep the
source field's `readonly` attribute.
The rationales behind this patch are:
* Enforce good practices, as the most common use-case for
related fields is the same as for compute fields: to read data.
* Avoid errors where some user saves a form view which contains
a related field that the user doesn't have write access to.
This commit adapts the business code to changes introduced by
the change to related field's default readonly value in order to
keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
A recent modification of the float and integer
formatters allowing the rendering to be human readable
causes a bug in the percentage formatter for large values.
The reason is that the latter formatter uses formatFloat (wich can
now produce 'numbers' like 3k) and then parse the result. In the case
of 3k an error is raised since 3k is not recognized as a true number.
This fixes avoid to parse the number in case it has been formatted
to be 'readable'. Note that the parsing was essentially used
to produces better percentages like 10% instead of 10.00%.
This is not necessary in our case since utils.human_number takes care
of the unwanted (not all) decimals for us (the original number is always
rounded by utils.human_number).
While start and stop are required fields, it is possible to trigger the
computation from the UI before saving (e.g. create an event, set no date, check
"all day" checkbox).
Fixes#27265
Previous system was strange: you were able to choose a body color but
not a body background when you were in full layout mode.
As transparent colors will soon be able to be chosen by the user, it
makes even more sense to give that possibility as the user can set a
body background pattern and a transparent footer color to let it
appear. Choosing a transparent background image which will be mixed with
the body color is also a common feature.
Also changes boxed layout option to use a white background for the boxed
content (we should maybe give the opportunity to the user to choose that
color instead of using always white).
When getting the context of res_users, all the fields are read but if
the schema is being modified and the modifications are not yet commited
in the database, this leads to a bad query.
With this commit, a read is used to fetch only the needed fields.
Thanks to @RCO for finding this issue that only occurs in specific
planetary alignment.
closesodoo/odoo#27263
* Create a new invoice and validate it.
* Create a new bank statement, without having the partner filled in.
* Reconcile the bank statement to the invoice.
* Open the generated payment.
Before this commit, the field partner and partner type are empty in the
payment.
Now, the field partner is filled with the invoice's partner, and the
field partner type is calculated.
opw-1917028
closesodoo/odoo#31399
- Create 2 companies C1 (USD) and C2 (EUR)
- Create 2 products P1 and P2
P1: company: C1; cost: 50
P2: company: C2; cost: 50
- Make sure to define the cost in both companies since it is a property
field (set it to 50 in all cases)
- Update the currency rates for both companies
- Create a pricelist in EUR, with a price based on the cost price.
- Create a SO in C1, select the pricelist previously created
- Add P1 and P2
The unit price for P1 is converted, while the unit price for P2 is 50.
This is not correct: both cost prices are set to 50, so the unit price
should be identical.
This is because the pricelist always assumes that the price retrieved is
in the product currency. In this case, this is not correct: the price
retrieved is in the company currency, since the cost price is in the
company currency.
Closes#30616
opw-1934443
closesodoo/odoo#31402
The cost of the product is a property field, meaning that:
- its value depends on the current company;
- its currency is the company currency
However, several views use the monetary widget to display its currency
with the default `currency_id` field. This can be incorrect, since the
latter is computed based on the product's company.
We introduce the new computed field `cost_currency_id` which has the
appropriate value and can be used in the views.
Closes#30616
opw-1934443
Thibault Delavallée