In this commit I provide a way for any part of the webclient to load a complete bundle of assets, JS and CSS.
The primary goal is to lazy load the complete o_spreadsheet package, including the library and all the custo that odoo includes
in it.
the endpoint /web/bundle/bundle_name will return a json structure describing the path to the JS and CSS files that have been generated by the client.
Those can then be loaded with the loadJS(...) function like any library.
The advantage of using a bundle, is that all the dependencies are respected inside that bundle.
closesodoo/odoo#76361
Task-id: 2576814
Related: odoo/enterprise#21804
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
When printing particular reports without specified record IDs, an indexError
occurs, therefore preventing the printing. This PR changes the way the data
is get from the url by using url_parse instead of string.split('?'), which
sets the data to an empty dictionary if no params exist in the url.
task-2552160
closesodoo/odoo#77471
Related: odoo/upgrade#2694
Related: odoo/enterprise#19808
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
* = crm_livechat, hr, hr_holidays, im_livechat, mail_bot, purchase, sms,
snailmail, survey, test_discuss_full, test_mail, web_editor, website,
website_livechat
- Create new model `mail.guest` for guests.
- Rewrite some RPCs to target routes rather than model methods so that
guests are able to use them.
- Patch JS and python models to support guests.
- Create a stand-alone page and boot the channel in it.
task-2494829
closesodoo/odoo#75496
Related: odoo/enterprise#20417
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit is part of the 2 factor authentication revamp.
The purpose is to avoid to display error modals when it's possible to only
display a notification toaser.
Task-2487630
Part-of: odoo/odoo#71142
Despite that Werkzeug documentation specify:
'location (str) – the location the response should redirect to.'
Werkzeug support URL as location.
So now Odoo will support URL for request.redirect as argument too.
This commit closes#73729
Re-introduce after discussion with AL the function that allow to specify
a custom placeholder for a specific model.
It has been removed because no more used since we use avatar mixin for
res.users and res.company. But it doesn't means that each model should add
his own mixin and controller and ... Keep it simple!
Use it for product and product template to have a default placeholder more
representative of the model.
Courtesy of xlu-odoo for this design
opw-2513801
closesodoo/odoo#73576
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This branch adds request.redirect on all requests.
In case of a front end request, we do an url_for to the location.
We removed redirect_with_hash that was only for retro compatibility
local_redirect has been renamed to redirect_query, and param keep_hash has been
removed and moved.
Default code for redirect is 303 now instead of 302.
Now redirect and redirect_query make local redirect by default, you need to
pass local=False to make external redirect.
All werkeug.utils.redirect has been replaced by request.redirect.
Http.redirect now use an http.Response type, and it become easy to add an
override like 'set_cookies' e.g.
Dispatch of a website.page return an http.response too, so we first need to
check if it is a cached version before to check if it is an Odoo Response.
Migrate your code:
http.redirect -> request.redirect(location, code, local)
http.local_redirect -> request.redirect_query(location, query, code, local)
http.redirect_with_hash -> request.redirect
Courtesy of odony for help and review ;)
closesodoo/odoo#72599
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Install the eCommerce (for the ribbon, in 14.0) and the Sales app
- Go to the Sales app -> Products -> Products
- (View List ->) select (a) Product(s) -> Action -> Export
- check "I want to update data (import-compatible export)" -> click on the "Ribbon" field (in 14.0, or another many2x field for wich the model has no _rec_name defined) to expand
Cause: the export page controller tries to access an undefined field (_rec_name)
Solution: the controller now uses a fallback method to retrieve the wanted field
opw-2566403
closesodoo/odoo#72748
X-original-commit: e31cb5be22de7db223318b4876bf725e15654fea
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: prro-odoo <proose@users.noreply.github.com>
In commit adf34b9001eb34e, we remove unused token param.
These token's parameters are still a leftover of the previous cleaning.
This commit fixes the export in Xls in view form that crash with:
closesodoo/odoo#72499
Typeerror: index() missing 1 required positional argument: 'token'
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit is the first phase of the conversion of the web/ JS
codebase to the owl framework. The impact of this commit is two-fold.
First, it rewrites the framework part of web with a new system of
services and registries. Services allow to execute code (e.g. do rpcs,
setup things) before launching the application. They can also expose
an API to be used by other parts of the application (e.g. a notification
service would expose a function to display notifications). Services are
often a good extension point for external modules that want to execute
code at webclient startup. Registries offer another way to extend the
application. They provide well designed extension points to add
elements/behaviors from the outside (for instance, to add a systray item,
an error handler...).
Second, this commit initiates the conversion of the webclient to owl
with a top-down approach, around those notions of services and registries.
The root of the web application is now an owl application. Among others,
the WebClient, ActionManager, Navbar, UserMenu, DebugManager, Dialogs,
services (e.g. notification, ajax...) have been converted to the new
framework/architecture.
Legacy views and client actions are still supported (and used). They
will be converted in the next months, and at some point, the support
will be dropped.
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Owl 1 has some issues handling comments. So when people were in odoo
debug mode, inheriting in extension mode a t template, the comment
added from the server would throw a frontend error.
For now, we comment it, waiting for better comment handling in owl.
closesodoo/odoo#70227
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The profiling tools can be useful to profile a test of some execution
point but this is not convenient to identify a problem on a running
instance.
With this commit, an option available in the debug menu allows to add a
flag on the user sessions to enable profiling of all requests. Each
request will be saved in a different 'ir.profile' entry, but will be
grouped under the same session.
The profiling can be activated on all sessions, even for a public user,
but only if profiling is enabled on the database globally.
This commits also adds a speedscope view to visualize saved results in
the web client.
closesodoo/odoo#66590
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Description of the issue/feature this PR addresses:
It is currently quite difficult to differentiate users. Most of the time, people
don't take the time to upload an actual avatar so everybody looks the same. This
PR generates a custom avatar with the users initials and random color to
differentiate them. For res.users, res.partner and hr.employee, image fields now
hold the binary image and avatar are used to show the image or svg.
Current behavior before PR:
Avatar had only random colors and was being saved in database, being inefficient
Desired behavior after PR is merged:
A new mixin defines image fields and in case no image is set, it generates an
SVG image with the user's initials and random color.
closesodoo/odoo#69819
Task: 2404630
Related: odoo/enterprise#18199
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since the changing of assets (8cc066173d)
the /web/session/modules route returned a stringified set instead of a list
After this commit, the route returns a list
closesodoo/odoo#70545
X-original-commit: 54e4a48996826dd8ea16a84517b46a847d6daf3f
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Previously, lazy-loading xml templates was only possible by fetching the
xml file directly, this meant that it was impossible to lazy-load an
entire bundle's templates with a single request. Additionally,
requesting the xml files directly meant that no inheritance was applied,
causing the need for a separate inheritance system using t-jquery on the
client-side.
This commit alters the /web/webclient/qweb route so that it now takes a
bundle id, meaning that it is now possible to lazy-load the xml from
arbitrary bundles.
task-2497943
closesodoo/odoo#70084
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Can be simplified a bit by using the newer features of
`tools.file_open()` and `tools.file_path()`.
Let's do it since the PR is touching these lines anyway
for the change of resource paths.
closesodoo/odoo#69614
Related: odoo/enterprise#17855
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
* The result of `plaintext2html` is fully controlled and
markup-safe (the first thing we do is escape the input).
* For `append_content_to_html`, we assume the inputs are HTML and the
output is thus always properly HTML.
Alternatively, we may want to `Markup("%s%s") % ...` and require the
inputs to be properly marked? That seems like a good idea.
* In `_replace_local_links`, applying re.sub will strip out the markup
mark, so store it and reapply it on output if necessary.
That one is a big gnarly, because if the input to ustr is
markup-safe bytes (e.g. qweb rendering output) then the output is a
Markup object, but if the input is str then the output is str, so we
need to check before and after unless... we update ustr to check for
subclasses instead of exact type?
* In `_prepend_preview` the issue is similar to that of
`append_content_to_html`, though in this case we should *not* trust
the input, so we can flag the "parent document" as Markup and format
the preview bit in.
* And since we're marking mail's jinja output as safe, do the same for
web and iot.
Sadly there doesn't seem to be any hook for doing that at the
environment level of jinja, so every `Template.render` site has to
be marked.
This commit changes the way assets are declared in Odoo modules.
Before: assets were declared in template files. Template bundles were
generated from primary templates, so technically any qweb template could
have been called as an asset bundle, with the 't-call-assets' directive.
Being standard qweb templates, they had access to standard HTML tags
(script, link, with or without raw scripts or style definition), qweb
directives (t-call, t-raw, etc.) and could be inherited by other
templates.
Now: assets are defined in the module's manifest and generated by the
't-call-assets' directive.
More information on the new system can be found on the updated user
documentation (see the "JavaScript Reference" section).
Task: 2352566
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
- Create a product with:
Cost: 60.80
Quantity On Hand: 999.0
- Go to Inventory / Reporting / Inventory Valuation
- Click on export all (little button next to "Inventory at date")
The field "Total value" have too many decimals: 60739.2000000004
This occur because of the multiplication: it yield the correct value
(60739.2), but every rounding attempt done, even in the ORM, will
mess up the representation
https://github.com/odoo/odoo/blob/042298f8c949fba470eda6ad90f94c95ca291030/odoo/fields.py#L1333
opw-2438384
closesodoo/odoo#67558
X-original-commit: 67cf82962688360cfe25c6b2118a7dbd17a6ee95
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
The purpose of this task is to clean up and provide clear export
file names.
Currently, When exporting data:
- From a pivot view, the file name is 'table'
- From a list view, the file name is technical name of model
so in this commit, Change the export file name as below:
- For list view quick export and standard record export,
the filename will be 'model_description(model_technical_name)'
- For pivot view quick export,
the file name will be 'Pivot(string set on view)(model_technical_name)'
and if string is not set then 'PivotUntitled(model_technical_name)'
In all the cases space and forward slash will be removed.
closesodoo/odoo#64123
Taskid: 2237840
Related: odoo/enterprise#15579
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When attempting to resize or crop an attachment through the '/web/image'
route, if the attachment isn't actually an image (even if the record's
mimetype says so) or doesn't match one of the format supported by PIL
(Python Imaging Library) - like Apple's HEIF - the request crashes with
a "500 Internal Error".
Although it makes sense to return a response with an HTTP error code, a
more sensible approach would be to return a "404 Not Found" response
instead.
The point by handling the Exception thrown by PIL and returning a 404
status code is to more closely match the semantic of this HTTP status
code. Getting a resized version of a non-image doesn't really make sense
as this resource doesn't exist at all ; hence the "404 Not Found"
response. On the other hand returning a "500 Internal Error" would
denote that a legitimate request failed on the server side, which is not
the case here.
Note: this difference of semantic, even if only visible in a regular
browser, has its importance in the mobile apps because we use it to
given a meaningful feedback to the user in case if failed HTTP requests.
Note: the mimetype detection could be improved to ease the handling of
this kind of errors but would require too much changes to be done in
stable branch.
Steps to reproduce in Discuss:
- rename an HEIF file with a ".jpeg" extension
- upload it in a chat window
=> the thumbnail in the chat window throws an HTTP error 500
opw-2417172
closesodoo/odoo#63772
X-original-commit: 873bc2aa5a8fcfc0664fc5ca70f789911873d583
Related: odoo/enterprise#15462
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Some ttf fonts used to sign are shipped does not come with a clear
licensing. Also some of them does not have accented characters.
With this commit, they are replaced with better ones and their
accompanying Open Font License.
Also, before this commit, any file in the font directory was read to be
rendered by the sign widget. With this commit, only `ttf`, `otf` and
'woff[2]' files are read, this allows to store the license file
alongside with the font.
X-original-commit: f4a9aec57b871806fb225bf91a941edb0fde5cbe
Some actions use 'non-standard' key in the action dict, to pass extra
parameters. In that situation the filtering of keys in `clean_action()`
strips valuable params, in an attempt to avoid leaking internal action
data.
One example of this is the dynamic action definition returned by
`open_yodlee_action()` in the account_yodlee module, which uses several
non-standard properties.
This commit alters the filtering logic in order to allow extra keys by
default, as long as they're not actual fields of the action model (and
therefore should not cause unintended "internal data" leaks).
A warning is also added to recommend passing those extra parameters in
the `context` and `params` action properties, which are explicitly
designed for this, by convention.
For cases where extra properties are returned and where the warning is
annoying, those properties can be explicitly _allowed_ by making them
virtual action fields, through a `_get_readable_fields()` override.
X-original-commit: 5cc3a6f2307be617c51e8d9c5f167acc60cc6287
5c4544fb29 reordered some of the
operations at the export toplevel, and in doing so moved the filtering
of the xid out of the `fields` list *after* that fields list has been
used to know what fields to export.
Meaning the fields list isn't filtered anymore, and requesting the xid
on a view would blow up due to a latter assertion checking against
that.
Fix the filter, although a better solution might be to strip out the
field upstream (in the fields list provided to the export wizard) such
that users wouldn't even attempt to perform this export.
An other possibility (possibly combined with the previous) could be to
only strip out the export of the xid based on the absence of an
``id`` field on the model, though that's somewhat risky: technically
views have no reason to be stable so a "record" could disappear or
move around without the ORM being aware, leading to dangling xids.
Fixes#46674closesodoo/odoo#62995
X-original-commit: adc25bcf67438675bc9b0d55975ce733d58b4fb5
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- Create a product with:
Cost: 60.80
Quantity On Hand: 999.0
- Go to Inventory / Reporting / Inventory Report
- Export as XLS
The header values have too many decimals: 60739.2000000007
The root cause is `convert_to_cache` returns this value:
https://github.com/odoo/odoo/blob/042298f8c949fba470eda6ad90f94c95ca291030/odoo/fields.py#L1333
In this case, `currency.round()` keeps the extra digits. Since the field
is not stored, the useless digits are kept.
A simple solution is to use `float_repr` on the non-stored float fields
to make sure that doesn't happen. Another solution could be to not
convert the floats to strings, but that doesn't seem intended.
opw-2378895
closesodoo/odoo#62265
X-original-commit: 2ebcbb16f113dee1416097b7a52f8068a40a34cf
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
For reports fetched through this endpoint, the error would only be
reported to the client, which may well ignore it entirely (e.g. show a
completely generic message which might as well be unhelpful and at
worst aggressively misleading).
Log the error locally before returning it to the client, so the info
is at least in the logs.
closesodoo/odoo#57411
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Doesn't seem used since it's been broken forever on python 3:
base64.b64encode returns binary data, on which json.dumps chokes.
Still, removing the endpoint on old stables seems a bit brutal so just
fix it.
closesodoo/odoo#56650
X-original-commit: 7fc9bc28986d69184df5a4fdeefbe09e4b39b8f0
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
/web/action/load is the public controller that Should be used by the
webclient to fetch actions
_for_xml_id is the default access method on actions that implements
fields filtering to avoid leaking server action code or other
information not needed by the webclient
Implementing whitelist of fields that can be access per model
New module for supporting two-factor authentication via time-base
one-time-password (TOTP).
Users (including portal users) can choose to enable two-factor auth in
their user account settings, by scanning a QR code and adding it to an
authenticator app, such as Google Auth, 1Password, etc.
When two-factor is enabled, password-based non-interactive RPC is only
possible by using API keys.
Co-authored-by: Olivier Dony <odo@odoo.com>
Before this, invalidations to the UID cache is not synchronised
between workers because it's an ad-hoc solution (so a user changing
their password or an admin disabling a user would only lock out an
attacker currently using the API of one of possibly several
workers). Shift the entire thing to ormcache which already has proper
support for synchronising cache invalidation between workers.
Also simplify the cache invalidation mess in Users.write because the
caches have been unified into a single registry-level LRU, so the
half-dozen cache clears on specific ormcached methods & models is
pretty much the same as repeatedly calling clear_caches on the current
model.
**However** registry.cache is trivially accessible from server actions
and safe_eval as long as they provide access to a model (through
`model.pool.cache`). Which is common, and an issue given we're very
much putting sensible data in there.
Fix this by renaming `Registry.cache` to `Registry.__cache`, this
requires few editions and mangled names are not accessible from
safe_eval contexts.
The alternative would have been to add more bespoke handling of the
uid cache to hook it into the cache invalidation propagation
machinery.
After discussion with (@)odony, fixing LRU access and using that seems
cleaner and less error-prone.
Note on lazy_property
=====================
Make Registry.cache / Registry.__cache into a regular attribute: the
overhead of the LRU is not that high (compared to that of the registry
itself), it's rare that we *don't* need it, and it's assumed to be a
persisted attribute (it's not just a cache) so making it a normal
attribute seems fine; and lazy_property doesn't work for mangled
names: the name of the property is mangled using the name of the
definition class, but the name of the symbol (fget) is not mangled so
lazy_property would set the __cache attribute but then Python would
lookup _Registry__cache, creating a new cache every access.
And we can't (always) mangle things correctly on `__get__(obj,
owner)`: `owner` is just `type(obj)`, meaning in the case of
inheritance the type we get is the type through which the property is
accessed rather than the one it's defined on. So it would work in the
cases where no inheritance is involved (such as Registry.__cache) but
not in general (lest we want to play around walking the MRO ourselves
to find the definition source, which doesn't seem worth it).
lazy_property *could* be made to work properly on Python 3.6+: the
descriptor protocol gains `__set_name__(name, owner)`, which is called
with the properly mangled name — and with the definition class to boot
(though there might still be issues when overriding lazy properties as
the override will be mangled & named differently... or maybe that's a
feature?). However we're still supporting 3.5 at this point, AFAIK, so
that's not an option. Plus it feels unnecessary / not very useful.
However add an assertion to `lazy_property` so it signals when we try
to use it on a mangled method (as otherwise it kinda sorta work in the
sense that the property / object is accessible but is in effect a
slower way to write a regular property).
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
- Install Sales and Accounting
- Go to Sales > Orders > Quotations
- Create a new quotation
- Add a product and in Order Line form, select a tax
- Save the Order Line
- Save the quotation
- Go back to quotation list
- Select (checkbox) the created quotation
- Select "Export" in Action menu
- In export wizard, choose "Excel" format and add field "Tax amount by group"
- Validate with "EXPORT TO FILE"
An error is triggered.
The issue comes from the fact that the value of "amount_by_group" is an array of tuples
and "xlwt" cannot write that type of value.
opw-2255054
closesodoo/odoo#51480
X-original-commit: dde2ca9943362b20853ab11b15fe1504c0b8d848
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When creating a new database, a random master password for it is
generated and strongly suggested to be used.
The motivation for this change is to have, by default, a secure master
password set for any Odoo deployment.
Often, users do not realise that, when making an Odoo installation
accessible on internet, anyone else can also access it.
Use autocomplete="new-password" for updating the master password and
play nice with password managers
When generating a new password, use autocomplete="new-password" as
well to prevent autofill of password potentially saved in password
manager.
Make the eye click to toogle on click instead of need to maintain.
closesodoo/odoo#45117
Task-id: 2091260
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This new modelling makes it easier to add new QR-code formats, and allows using all of them in website_sale and account.payment's form view as well (so, Swiss QR codes are now available there, while they were restricted to only invoices in the past). All barcodes are now generated as reports, from a dedicated route. This was only partly the case before : Swiss QR added a cross on top of the QR-code directly in the template, it wasn't part of the image returned by the route; now it is.
[ADD] base_qr_code_sepa: new module decoupling SEPA QR-codes generation from the base module
Each new QR-code generation option should thus be done in a dedicated module (or added to a localization) in the future.
[IMP] base_qr_code_sepa: update the generated QR codes to version 2 of the specification
Version 1 is still supported, so no need to backport this.
[IMP] l10n_ch: make Swiss QR-codes compatible with the new version of the specification (the old one is deprecated)
This will be backported to 11.0 and 12.0, as these QR-codes will soon replace ISR.
[IMP] account: make it possible to mark manual payments as sent with a button on the form view
This way, when making them directly with a QR-code (or doing a more classical wire transfer), people can keep track of what they already have asked the bank to do, and what they still have to treat.
closesodoo/odoo#44839
Related: odoo/enterprise#8262
Related: odoo/upgrade#992
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Vincent Schippefilt