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
Usecase:
- Create a planned transfer
- Add line with initial demand
- Create a scrap
- Click on button validate
The wizard asking for a backorder or not is diplayed. The UserError
that prevent to validate a picking without quantity done or reserved
should have been raised. The scrap moves are directly processed once
the user validates his scrap order. Validate a picking with only done
moves, will not have any effect.
closesodoo/odoo#31076
Usecase to reproduce:
- Create an internal picking from stock to scrap
- Add some scrap move inside due to scrap button in header
- Add some move with initial demand for future
- Mark the picking as done and validate it
- The wizard asking for a backorder appear -> Validate or No backorder
The moves with initial demand are duplicated(one new move for each
without intial demand nor quantity done)
A note is logged in the chatter with backorder False has been created.
There is a problem since _action_done on a scrap move from scrap model
will process the scrap move individualy but will create a back order
(commit e088acbc0f try to fix this issue)
However when we create a picking that goes to scrap location, the back
order will not be created since all moves are scrapped.
With the current configuration we can't guess in _action_done if
it comes from scrap or picking validate that goes to a scrap location.
The current solution is to use a context key in order to indicate if the
call come from picking validate or scrap. If it comes from scrap do not
create a back order no matter the case. If it comes from picking, follow
the standard beahvior with a backorder or not.
opw-1934835
Before this commit, the t-lang on a t-call was not
propagated into the context's of the callee template
It resulted into mismatch translation and formatting in the final
rendered template
i.e. having a t-esc with a qweb widget float would take the wrong float format
After this commit, the t-lang parameter alters the context of the template
and t-esc with widgets are translated
OPW 1939989
closesodoo/odoo#31291
Have a partner which is a company, with some children
Click on the action "Portal Access Management"
Before this commit, only the children of the company is selectable in the wizard
but not the company itself
After this commit, the company is part of the list
OPW 1931920
closesodoo/odoo#31344
compute_sudo has no effects on non stored computed fields.
It was technically already said in the previous lines (REcomputed) but
it was not particularly explicit
closesodoo/odoo#31320
compute_sudo does not do anything when the computed field is not stored.
This fixes an issue where user not part of base.group_erp_manager
couldn't modify res.partner
opw-1942803
- Changed the binary_content method
to make it more generic and allow alternative ways of checking
the access rights by using a new method check_access_mode.
Reason: Asked by ODO following documents' security review.
- if all pages are processed, splitting a pdf will
archive the original attachment.
Reason: FP feedback.
Task: 1853490
qsm-odoo