* merge report_invoice_document and report_invoice_document_with_payments templates
* define new generic method _get_name_invoice_report that let us to
print a different report, this method can be inherited by each localization
to set their custom report
* change report templates to use the new method.
Allow configuring a webhook in Stripe to send s2s notifications to Odoo
when a Checkout payment is completed. Note that SetupIntent and
PaymentIntent events are not listened to, since they are handled 'live'
with the customer actively present; the main use case for Stripe
webhooks is a Checkout session that gets interrupted before the customer
is redirected to Odoo (e.g. network loss, browser crash, closing the
tab, etc.)
The webhook should be configured to send its events to
<base_url>/payment/stripe/webhook and should only subscribe to
checkout.session.completed events to avoid spamming the Odoo server with
useless notifications.
closesodoo/odoo#52754
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Extend support for all currencies listed in the SIPS documentation,
including the decimal numbers per currency. Move this hardcoded data
is a less annoying place.
Remove unnecessary code (e.g. checking if there is more than one payment
with the same reference, which can't happen due to a SQL unique
constraint from the payment module).
Code clarity while I'm at it.
Task-2259942
closesodoo/odoo#51473
Related: odoo/upgrade#1216
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Prior to this revision, setting the provider to the 'test' mode caused
hardcoded values for merchantId, secret and keyVersion to be used
without any possibility to override them.
While somewhat useful, it was quite limiting since it used the 'simu'
environment of Atos Wordline, preventing you from testing any other
platform and from using the 'test' environment for Atos.
This revision removes these hardcoded values, which gives more
flexibility as far as testing goes at the cost of a bit more setup
(since you might need to change some values manually, notably the
keyVersion).
Task-2259942
The config param 'sips.key_version' was introduced "some time ago"
in revision a62480ad0f to allow setting the `keyVersion` POST param
to an arbitrary value, allowing other SIPS-comptatible providers to be
used with this module.
This revision (finally) converts this fix to a proper field.
Task-2259942
PURPOSE
Currently it does two RPCs to refresh followers on thread:
1) To get follower ids
2) To get followers detail
SPECIFICATION
While refreshing followers on the thread, perform only one RPC call.
LINKS
Task-2243180
PR https://github.com/odoo/odoo/pull/54437closesodoo/odoo#55989
X-original-commit: 1fd445fb55810b97ed7a6dfe694e471891c6a3bc
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit adds a trash icon on the snippet overlay to delete the
snippet without using the left panel button.
task-2314805
closesodoo/odoo#55612
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The `PackageLoader` jinja's loader purpose is to discover template files
given a python module path. It was necessary to register a special hook
into the import scheme of Odoo to support `import crm`, `import openerp`
and `import openerp.addons` like module path.
Since the support for those old module paths is deprecated since v13 and
the jinja's team shows desire to remove support to `pkg_resource` utils
as highlighted by #50552, it is better to remove it.
closesodoo/odoo#53515
Task: 2282681
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
* Not sure how the tour passed during merge as it would not be looking
for the button in the right tab, it would fail locally, fix this
issue by properly switching to the Account Security tab
* add the missing test of RPC (which should not work on an account
with totp enabled)
* also reorder ops & fix comments: turns out `totp_login_enabled`
checks that totp is enabled *then disables it*
closesodoo/odoo#55979
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Setting the totp secret is a significant change to the user's
auth-ability, and as such should be taken in account for the session's
validity.
For convenience, update the user's session in-place to avoid logging
them out.
Remove all acccess rights on `ir.actions.*` models.
Interacting with the models is done using sudo or via the `/web/action/load` controller.
Part of task 8203
closesodoo/odoo#53335
Related: odoo/enterprise#11797
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
/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
To trigger a run of a server action, one must have a group specified
or a write access on the model.
CRM: only access lead, crm.team is readable by employees
Website: all users can access, action_dashboard_redirect takes care of the group
Browse in sudo and allow to access and run in sudo if the user belongs
to the groups defined.
If the user does not belong to the group, the run must be called in
sudo or with a priviledged user.
If no group is defined, the user can execute the action if he can
write on the target model.
Safe actions (e.g. crm.action_your_pipeline) need to have the correct
group on it.
Inspired by the logic of access to ir.ui.view, all records are private
by default except if explicitly specify a group value.
A single anglo saxon line was created in the pos.session journal
entries, even if some products were returned. We now distinguish
positive from negative lines.
E.g. Selling 10 Product1 (cost=10) and returning 5 Product1 used to
create the following line:
```
Stock Interim Account (Delivered) 0 50
```
and now creates the following lines:
```
Stock Interim Account (Delivered) 0 100
Stock Interim Account (Delivered) 50 0
```
Task ID: 2126521
closesodoo/odoo#55086
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
b8359c55e6e57035ffa3b10bfa5294e22a74e837
An user with recruitment/officer (user) permission on hr_recruitment
could not create applications anymore because doing so imply a write to
hr.recruitment.stage
opw-2305646
closesodoo/odoo#55805
X-original-commit: 01fbb34213358f216011ae5b1c1fd6ec8dd80bdf
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
`struct_rusage.ru_utime` and `struct_rusage.ru_stime` are float
seconds.
`setrlimit()` takes a tuple of *integers*, and recent versions of
Python have started triggering warnings:
DeprecationWarning: an integer is required (got type
float). Implicit conversion to integers using __int__ is
deprecated, and may be removed in a future version of Python.
Convert the soft cpu time limit to an integer explicitly to suppress
the warning.
closesodoo/odoo#49710
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
PURPOSE
Make sure the Rainbowman animation is rightly triggered whichever way the user
marks the opportunity as won. Especially relevant for the onboarding as we want
to show the first rainbowman to users completing the tour.
SPECIFICATIONS
Now the rainbowman and its finely-tuned message are displayed to the user when
he uses the statusbar, mark lead as won using action buttons or drag and drop
a lead in the won stage in kanban view.
LINKS
Task ID-2287758
PR #54553
Steps to reproduce:
- Go to the website shop
- Add a product in the cart
- Add your address and click on checkout
- On the checkout, enable Terms & conditions
Bug:
The button was always enabled even if the check box with the terms & conditions were not
checked.
opw:2313437
closesodoo/odoo#55821
X-original-commit: 0415da51960819ec9c989e15a9229bd6d583ba1b
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Adds support for two-factor authentication (2FA) via time-based one-time-passwords (TOTP),
compatible with mainstream authenticators like Google Auth, 1Password, etc.
- Add support for personal API key that can be used for non-interactive RPC scripting, including
when 2FA is enabled (password-based non-interactive RPC auth gets disabled by 2FA)
- Both features can only be enabled/disabled after an extra password check, made possible
by a new "identitycheck" feature.
- Adapt user profile and portal to allow managing those new security settings.
closesodoo/odoo#33928
Related: odoo/enterprise#9112
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
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>
Follow-up on 6edb749534, where default
`autocomplete` values were introduced as default for password fields,
according to the new autofill specs.
This patch allows developers to force the "autocomplete" attribute value
on password fields, in case there really is a need for a value that is
not `new-password` (which BTW now triggers the password generator wizard
in many browsers).
It is useful for example when a backend form really needs to ask the
user for their current password, so the correct `autocomplete`
value is `current-password`, as on the login form.
* allows portal users to update their password
* and manage their API keys
* any anything technical / security related we may need to add in the
future
Also bridge module for the password meter (auth password policy).
* ability for a user to request / create keys associated to their user
* overrides can block RPC solely through API keys, by overriding
`_rpc_api_keys_only()` (to require API auth even in
situations where the user has not requested it themselves)
* hash keys just in case as we can do so and might as well, add a
cleartext index (first 4 bytes of 20) to avoid blowing up the DB if
a user decides to create millions of keys for some daft reason
* users can delete their own keys, admins can delete (invalidate)
anyone's keys
* `scope` on API keys can be used to restrict usage to certain
kind of applications, so API keys can be used for other things
than global authentication. New keys manually created by users
have no scope by default so they are valid everywhere (global
keys). RPC auth (stateless XML-RPC/JSON-RPC) requires global keys
Co-authored-by: Florimond Husquinet <fhu@odoo.com>
Co-authored-by: Olivier Dony <odo@odoo.com>
* migrate website to overriding web_login less (still needed to flag it
as website-enabled) and use _login_redirect for its login redirection
override needs
* modify portal and website to not replace / shortcut the redirection
workflow, so it's possible to override those properly if / as
necessary
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).
Similar to github's sudo mode, my understanding of the intent is to
avoid third parties being able to perform sensitive / serious
operations when leaving a logged-in machine unattended.
This v1 only handles protecting "action methods" (methods called
through buttons and intended to return action descriptors), although
they can be used to "lock out" any methods they won't be able to
prompt and the caller will likely be surprised.
The browser itself would get mostly cleaned up between tours, but the
session object would not get cleaned, and apparently in some cases
that could lead to an incoherent session: a tour would add data to the
session which the next tour (logging in as a different user) would
not (fully) override, leading to a session inconsistency and a Session
Expired exception during the tour.
Fix by not storing the session on the test object, the session is
created during authentication then set on the opener & browser.
Allows accessing various keys, especially whether this is an
interactive login or not.
Also have the xml-rpc `login` delegate to `authenticate` instead of
having its own half-assed implementation.
And remove some dead code: as far as I can tell, Session.authenticate
is never called with a uid.
This commit switch the cash control opening mangement from the backend to the front end of the point of sale.
task_id: 2258817
closesodoo/odoo#55741
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This commit fixes several small issues in the test_event_full tour that was
relying on selectors that have been since reworked.
In addition:
- Set the track we set the reminder to in the future so that the button appears
- Avoid going on the exhibitor page because Jitsi will trigger an error
- Make sure we go on the registration confirmed page
Task #2317947closesodoo/odoo#55956
X-original-commit: 11b7f4446ddec6ab237ed6076838bfbbaca03be6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Katherine Zaoral