We don't want two different reports for the same thing.
We will therefore lose the ability to print the "quotation builder" report built with the snippets.
PR: #27293
task-1889346
* website_mass_mailing, website_twitter
A snippet option describes where standard snippets can be dropped in the
page (which is currently in oe_structure elements or html fields, except
for the footer which can only have one snippet). Some external snippets
in other apps or themes were not using this snippet option but defined
their owns which were not adapted to the correct drop locations.
Account type of other income should be of type 'income' and not 'other'
Filter 'Assets' in chart of accounts view is not working correctly due to typo in the filter.
This is already handled in the l10n_multilang module for countries with several languages
Same as the account names, it should not be translatable in standard
* reduce number of patterns: using localised month names is useless
since we're not setting the locale so it always uses the server's own
* avoid going through the entire strptime machinery: lift the bits of
TimeRE we're interested in to get regex bits out of strptime patterns
and just to an re.match to check whether value & pattern match
Further possible optimisation: cache REs and only compile user-provided
patterns dynamically.
When an attachment is requested with an access_token, a server error
would occur in some situation.
With this changeset when an access token is specified:
- returns a 404 error if the attachment does not exist
- returns a 403 error if the attachment has no access_token
Without this change, the added test would fail with:
```
status = test_access(access_token='Secret')
self.assertEqual(status, 403,
"no access if access token for attachment without access token")
| if not consteq(obj.access_token, access_token):
| TypeError: unsupported operand types(s) or combination of types: 'bool' and 'str'
status = test_access(access_token='Secret')
self.assertEqual(status, 404,
"no access with access token for deleted attachment")
| if not consteq(obj.access_token, access_token):
| odoo.exceptions.MissingError: ('Record does not exist or has been deleted.', None)
```
close#26647
opw-1884419
closes#27275
Co-authored-by: Wolfgang Taferner <wtaferner@users.noreply.github.com>
The inventory overview is made of kanban cards of picking types. There is a link to the picking type settings on each card. Before this commit, the link was partially ouside the card.
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).
Gert Pellin