- When trying to timesheet on a task that is linked to a sale order
line from a different company than the user's current one.
An error is triggered due multi company access rights issue.
This is due to two computed fields that are not computed in sudo
mode.
They make more sense as `computed_sudo` fields as they are only
computed stats and are not leaking private data.
closesodoo/odoo#64828
X-original-commit: 721378370f5aadb476e8cc606be9a41a3ffad74a
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Since the wizards now requires ACLs, the access rights
set on the lead forward partner and the lead assignation are
incorrect.
Only the Sales/Administrator are able to use them.
With this commit we introduce the intended behavior where
the sales are able to perform those tasks.
closesodoo/odoo#54568
X-original-commit: 3081ca828e4a7de3861ee5b1fb9600b248c3ea07
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- The HR staff may not be able to accept/refuse/cancel leaves if the
module `project_timesheet_holidays` is installed.
This is due to the commit c9da157149
introducing a manual check on the current user's group without
checking if the current environment is in superuser mode.
- Also fix the test verifying the access restriction, which meant to use
a different user, but did that with sudo(), obviously defeating
the fix. sudo is not used to switch user anymore, that `with_user`.
closesodoo/odoo#55274
X-original-commit: 75a166f1d115cc712bb39e7711d0fcb173732650
Related: odoo/enterprise#12149
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
- The field `allowed_user_ids` is only accessible to Project Manager.
When trying to duplicate a task, an access right issue is raised
if you are not project manager.
This is due to the fact that when trying to duplicate this field is
read.
To avoid this issue, we specify that this field should be copied thus
not be read.
closesodoo/odoo#54509
X-original-commit: 95dedd23cc7a7d66d7a7dc17b9f9ac4f5473e226
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- The payment link generated by using the wizard
`payment.link.wizard` are overriden to generate
URL linked to sale orders.
If so, we want the payment acquirer displayed to
be in the same company as the sale order.
closesodoo/odoo#49018
X-original-commit: 8c299efb6cb4355cec39cdedd8d7c3134f53d199
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- A bug has been introduced by the PR https://github.com/odoo/odoo/pull/46719
This issue prevented flushes to database when no `uid` is set in the
current environment.
This happens when database changes are made in `auth="none"` routes.
In a MonoDB setup this was working because Odoo consider `None`, `False` as
`null` and was always bound to a database.
Nothing prevents to write `null` in the columns `create_uid` and
`write_uid` in database.
The PR that introduced the bug wanted to block the cases where
`uid` is an instance of the class `RequestUID` to avoid `Cannot adapt
type` errors.
So testing that `uid` is an integer isn't enough.
Two fixes were possible here, either check if `uid` is an instance
of the class `RequestUID` or if it is either an integer, `False` or `None`.
To avoid noise and imports from `odoo`, we test that `uid` is an instance
of `None`.
The case where it is `False` is already tested in the python code:
```python
isinstance(env.uid, int)
```
(manual) forward-port of odoo/odoo#48685closesodoo/odoo#48693
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
- In some cases One2many fields defined as computed without
inverse field defined could cause crashes if it is used
in a search.
This should not be done, but shouldn't crash either.
With this fix, trying to search on one of this fields
would just print a warning.
closesodoo/odoo#46742
X-original-commit: 4b4f1623590f2e872c565e8e56002bc3f5bf9efe
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- At invoice creation, the stored fields that depends on `invoice_lines`
are computed to be stored.
This can slow down the invoice creation for a database with a lot of
records on `account_move`.
This commit speed-up the invoice creation by using SQL Joins to
speed-up the searches.
We cannot use `auto_join` on the `invoice_lines` field since it is
not supported on many2many, thus we do it in SQL.
closesodoo/odoo#46233
X-original-commit: b39e17c464775564faa7d0f10e675d47fa026234
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- The form view on `res.users` displays information about
how many record rules, ACL and groups are applied to the users.
In some cases the current users may not have the required
access rights to compute those values.
To fix this issue, the computed fields are now computed
in `compute_sudo` mode
closesodoo/odoo#46149
X-original-commit: 653f81f49ba4d92648eb04209cdbe73894dfac08
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- In some cases when trying to open a discuss conversation a
traceback can occur because of the usage of a local variable
before its assignation.
closesodoo/odoo#45867
X-original-commit: 47bec812a36c1e41bdb525439dfd18a208e1dd79
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- When browsing the blogs, in some cases the code need
to fix the URL to properly slugify the tags.
When so, the code crashes since it is trying to maniapulate
a `werkzeug.wrappers.Response` as if it was a `dict`.
To avoid this, we directly return the `werkzeug.wrappers.Response`
instead of trying to modify it.
closesodoo/odoo#45658
X-original-commit: d26ba7e4b71138a324bbb729f406cbad562881e7
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- When rendering a website page, exceptions might happens.
If so, an error page is displayed, to do so we create
a new psyscopg cursor to read the view in database and render it.
But if the current (failed) transaction was holding a lock, the new
cursor might have to wait for this lock to be released further
down the line. However, this will only happen after the
request is done (and in fact it won't happen). As a result, the
current thread/worker is frozen until its timeout is reached.
So rolling back the transaction will release any potential lock
and, since we are in a case where an exception was raised, the
transaction shouldn't be committed in the first place.
closesodoo/odoo#44085
X-original-commit: 7a61c89da5ccaed983275eb5f4986475ebf8b48d
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- The module `website` instanciate the environment bound to
request before `_dispatch` is called.
This causes issues with with routes that create their own
psycopg2 cursor.
To be more precise, the issue that allowed us to discover this
instanciation is linked to the module `auth_oauth`.
The route `/auth_oauth/signin` is a `none` route that receives
a database name. It uses the db name to create a cursor and
an environment manually to process the OAuth signin, log-in the user
then assume it is safe to now use `request.env` to process the rest
of the code.
But here, since a cursor has already been created in `request` before the
route had the chance to commit its changes to `res.users`, the
changes made in the route `/auth_oauth/signin` are not available.
And this causes issues with the computation of the session token
done in the method `_compute_session_token` in the model `res.users`.
It uses the field `oauth_access_token` to compute the session token.
But since, the cursor in `request` is in a transaction that is not
yet aware of the changes made on this field, it will compute a
session token using the old `oauth_access_token` and store this
outdated token in the client's session.
Then here depending if you are using a multi-worker or a multi-thread
Odoo, you either are never signed in or your session is expired
after a cache cleaning (the method `_compute_session_token` is cached).
closesodoo/odoo#42808
X-original-commit: ceec103826ae2a18c63b48c17850d035e352fa3b
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- Avoid to crash when trying to render an employee's org chart
when in a different company than yours.
- Retrieve the context from the current environment instead of
the `_check_employee` function parameters.
closesodoo/odoo#37251
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
- Before the change of `sudo` and `with_user` the code was non sense, it
was doing a `self.sudo(self._uid).check_access_rights('read')` which
was doing nothing.
But now with `with_user`, doing a `self.with_user(self._uid).check_access_rights('read')` breaks the
flag `superuser`.
Meaning that if the code was called using `sudo` it was bypassing the
ACL tests.
closesodoo/odoo#35896
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- With the new ORM optimizations, the cache doesn't depend on the
context and the key context that are really important for the
computation of a value must be explicitly set.
Setting `force_company` as a determinant will make sure that the
company on the environment is taken in account.
- Since commit https://github.com/odoo/odoo/commit/f5cd483216af01001f44a41f7d48f042b9f56ff9
the method `_lang_get` doesn't fallback on a language if the asked language
isn't found.
This causes issues with `formatLang` that uses the language on the
context, which is the language set on the client browser (in most cases).
Meaning, if 'en_US' is the only installed language and a customer
has set his browser to `fr_FR`, when calling `formatLang` this will
crash since no language has been found and `format` on `res.lang`
requires a singleton.
closesodoo/odoo#35633
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- When creating a vendor on lunch without setting explicitly the
`responsible_id`, `default_get` should return the current user id.
Instead it returns the current user's partner id.
closesodoo/odoo#34759
Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>
- On the HR module, the field `parent_id` is added on `res.users`.
The issue here, is that `res.users` inherits the fields from
`res.partner` where `parent_id` is already defined.
This causes issues when trying to read the parent `res.partner`.
Issue found by @rrahir
closesodoo/odoo#34059
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- When validating a payment an "expected singleton" exception is
raised due to the fact that we are using a recordset with multiple
record instead of a recordset with a single record.
OPW-1981632
closesodoo/odoo#33767
Signed-off-by: Christophe Simonis <chs@odoo.com>
- On mobile grouping by a field crashes.
This is due to the code assuming a function parameter
is always passed where it is actually an optional parameter.
closesodoo/odoo#33891
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- Since 12.2 when a record rule forbids you to access a record
an error message is displayed with the list of the record rules
that have forbid the access and an example of the forbidden records.
The issue here is that a specific message is displayed to warn the
user that the record rule may be a "Multi-company" record rule.
To do so, it checks if `company_id` is present in the record rules'
domain but if the domain is empty it crashes.
OPW-2004827
closesodoo/odoo#33801
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- If a channel has only the current user as the partner the method `channel_info` crashes.
This can happen in the case of a partner talks to an other partner in
discuss.
Then these two partners are merged using the CRM partner merge
feature.
The channel has now the same partner in the channel twice.
The current code doesn't handle this case and crashes.
closesodoo/odoo#33274
Signed-off-by: Christophe Simonis <chs@odoo.com>
- When tyring to test a survey as a "Survey User" you are redirected to the
homepage.
This is due to a faulty access rights check that only allows "Survey
Managers" to test them.
closesodoo/odoo#33132
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- If the current user doesn't have write access to `hr.leave` or
`hr.leave.allocation` and tries to modify the manager (`parent_id`) of
a `hr.employee` record, an access right issue is raised.
This commit fixes the issue.
OPW-2000569
closesodoo/odoo#33542
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- When changing the `holiday_type` of a leave allocation while having an
employee set and if this `holiday_type` has as its value `employee`
the field `employee_id` is set to False.
This is not the intended behavior. We want the field `employee_id`
to be filled if the `holiday_type` is set to `employee`.
closesodoo/odoo#32886
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
- The overdraft setting of lunch is company dependent but had no
icons specifying it on the settings view.
This commit adds the icon
closesodoo/odoo#33761
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- When displaying the organisational chart an access right error can be
triggered if the current user cannot read employees from other
companies and if one of the displayed employee's manager is in an other
company.
closesodoo/odoo#33576
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- If you are a portal user when trying to access the validation queue
an access right error can be triggered when trying to read the post's
user name if the record rules don't let you read on this specific
user.
closesodoo/odoo#33626
Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>
- The added field `phone` on `res.users` shadow the field `phone`
inherited by `res.partner`.
The issue is that the field `phone` on `hr.employee` can be read only
by the employee or the HR team.
A lot of views tries to display the field `phone` expecting the one
declared in `res.partner` which should be readable by everyone.
But the one declared in `res.users` shadows it.
closesodoo/odoo#33569
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- There's a constraint limiting the number of contracts an employee can
have.
This constraint take in account closed contract which cause issues.
For example if you have to sign a new contract for an employee with a
running contract, you'll have to close the current running contract.
But if this employee already has closed contracts, you won't be able
to close it since they are detected as ""running"" contracts.
closesodoo/odoo#33294
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- Since the performance commit @c42ccf2ca7f0a600a0dd7e3b4dd8bacd7a5c6513
the lunch products are displayed only if you have already ordered it.
- Added indexes on `lunch.order` to speed up the SQL request.
closesodoo/odoo#33336
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- When validating payments on the payment process polling page
errors can occurs and the tracebacks aren't logged which doesn't help
when trying to understand the issues.
With this commit we display the traceback instead of shadowing them.
closesodoo/odoo#33537
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- When processing payments on the payments processing page,
`psycopg2.OperationalError` can be raised.
We do not want those exceptions to be displayed to the customers,
instead we want the polling page to try to process the payments again.
This commit hides the display of psycopg2 operational errors.
- This commit also fixes the "processing your payments" message being
hidden after the first polling, no matter if the processing has succeeded or not.
closesodoo/odoo#33462
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- The method `_is_available_on_website` on `product.pricelist` access to
the field `code` which is limited to the group `base.group_user`.
This causes issues when the method is called by a non internal user.
closesodoo/odoo#32123
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- The creation of leaves using "no validation" are not possible
if the `SUPERUSER` is not in the "Holidays / Team Leader" because
the validation is made using `sudo`.
OPW-1951316
closesodoo/odoo#31952
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- The attachments in the tasks page on the portal can be accessed by
clicking on them.
They are delivered by the controllers at URL `/web/content/XXXXX`.
By default when enabling the Content Delivery Network feature on the
website module, the content delivered by the controller
`/web/content/` is done through the CDN which has no user account,
thus may not have access to the attachment.
To fix the issue, we disable the CDN feature for the attachments in
the tasks portal page.
OPW-194571
closesodoo/odoo#31924
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- When creating a user from the "Grant Portal Access" wizard, the code
checks for duplicate users.
It does so by checking if there is a user with the same login as the
one we want to create.
The check is case sensitive which could lead to issues.
For example a mistyped email (with a uppercase somewhere) could fail
the duplicate user check.
Since emails are not case sensitive, we want the check to be case
insensitive too.
OPW-1932918
closesodoo/odoo#31818
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- The fetch of recently/most clicked links was not working due to the
fact that the widget handling this feature had not parent, thus not
having access to ajax.rpc to make rpc calls.
closesodoo/odoo#31712
Signed-off-by: Christophe Simonis <chs@odoo.com>
- Since the commit 5fcf891e07 an issue has
been introduced in the `analytic.account.analytic` name_search method.
In some cases searching through analytic accounts will return no
results when it should.
The issue is due to a bug in `expression.py` that doesn't correctly
handle the fields in `auto_join`.
The issue is described here https://github.com/odoo/odoo/issues/25175
and will be fixed by the ORM team.
closesodoo/odoo#31628
Signed-off-by: Christophe Simonis <chs@odoo.com>
- `hr.leave` and `hr.leave.allocation` should have the same record
rules, otherwise leave approval behavior can be unpredictable.
As a Holidays Team Leader:
For example you could see the approve button on a leave but cannot
approve it because the `_check_holidays` fails
closesodoo/odoo#31620
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
- Allow users with the "Holidays Team Leader rights" to approve the
leaves of the employees they manage.
closesodoo/odoo#31586
Signed-off-by: "Christophe Simonis (chs)" <chs@odoo.com>
- When selecting "Unpaid invoices" or "Invoices to validate" on the
accounting dashboard, the list view opened doesn't filter with the
journal selected.
closesodoo/odoo#31397
- When having multiples contracts, at least one open and one closed, we may
not be able to request a leave.
This issue is triggered if the closed contract has no end date.
The code checks if the leave you try create overlap over multiple contracts.
But if a contract has no end date and is closed, the check may never
succeed.
So if a contract has no end date and is closed we don't take it in
account.
closesodoo/odoo#32909
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- When retrieving lunch orders for specific users, the search could take a
long time to be resolved.
To fix this issue we rewrote the SQL View that retrieves the
information for lunch orders.
closesodoo/odoo#32908
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
- When changing the user of a `hr.employee` record, access rights errors
could be triggered.
Those errors are triggered when a record (for example a leave) is
linked to this employee and the current user has limited write
accesses by record rules on this record.
closesodoo/odoo#31032
- An eCommerce cart is a quotation linked to a website.
- The feature to consider a cart as abandonned wasn't correctly checking
if the quotation is linked to a website and flag regular quotation as
abandonned carts.
This causes issues since Sales may wish to send the quotation by mail,
but the button is hidden and replaced by the button "send recovery
mail" which send an email with a specific email template.
closesodoo/odoo#31103
- It was impossible to add attachments on the `account.bank.statement`
form view due to the chatter not being displayed.
This commit add the chatter widget to the Bank Statements form view.
closesodoo/odoo#31098
- When a record has `website_published` field set at True the method
`binary_content` on `ir.http` should bypass the access rules and
always deserve the content.
This wasn't the case due to a mistake on the code. The code is
checking the access rules and may in some cases not return the
content.
closesodoo/odoo#31068
- When merging leads that creates a partner, an error could be thrown
due to the `res.partner` `default_get` method that reads values from the
lead that creates the partner.
The issue is due to the fact that the `crm.lead` record is merged (and
unlinked), trying to read it will cause an error since the records
doesn't exists anymore.
This fix checks that the `crm.lead` we are trying to read from exists.
closesodoo/odoo#30895
- The method `_get_available_payment_input` that returns the available
payments acquirers and the payments tokens for a specific user never
returns the payments tokens linked to a non s2s payment acquirers.
This is wrong, the payments tokens should always appears no matter
what are the acquirers' payment flow.
The payment flow is used only to specify where the customer should
input his credit cards details, either on Odoo or on the payment
acquirer's website (or popup).
Once a token is created, it is safe to process it since no credits cards
details are stored on the Odoo database.
closesodoo/odoo#30258
- If a customer pays an invoice using a credit card, the payment is
taken in account but the invoice validation isn't processed until the
Payment Processing cron do it.
We want the invoice to be validated as soon as possible.
To do so, we need to redirect the customer on the payment processing
page that take cares of validating the payments.
OPW-1913876
closesodoo/odoo#30217
- When installing an accounting l10n module, the method `try_loading_for_current_company`
is called and could cause a deadlock.
The deadlock is caused by the fact that if the installation is started
via a web request the code tries to retrieve the current user's
company by doing `request.env.user.company_id`.
This causes issues since the installation code has its own postgresql
cursor while calling `request.env.user.company_id` will create its own
cursor.
So two cursors exists for the same Odoo worker.
The installation cursor asks for a lock on `res_users` while the
second cursor (the request one) will try to read on `res_users` and
wait the first lock to be dropped.
The lock is never dropped since the python code isn't running anymore
waiting for the `request.env.user.company_id` to be completed.
Causing the deadlock.
To fix the issue, we avoid the creation/usage of a cursor created by
`requesŧ`.
So to retrieve the current user's company, we read the user id on the
request's session, then browse the `res.user` record with the
installation cusror.
Fix issue introduced by commit d40956c790closesodoo/odoo#29927
- Portal users do not have the rights to read on project.project.
This causes issues on the page "/my/tasks" as it is trying to read the label_tasks and the name of the tasks' project.
To address this issue we read those two fields using sudo
Fixes#30127
opw-1925720
closesodoo/odoo#30955
- The field `signup_valid` was computed and stored using the `superuser`
env, which causes issue since it means the value was computed for the
wrong environment.
Using a compute_sudo instead of manually calling `sudo()` fixes the
issue.
e.g: reading signup_valid using a regular user (non superuser) will
always return False, while doing it as the superuser will return
the correct value.
closesodoo/odoo#30954
- The `_write` override on `sale.order` create a Next Activity for the
SO's salesperson when changing the SO `invoice_status` to upselling.
If the SO doesn't have a salesperson this code crashes since `user_id`
is required on Next Activities.
To avoid this crash we create the Next Activity only if a salesperson
is set on the SO.
OPW-1914087
- The payment transaction processing cron retrieves all the transactions
that need to be processed.
In some cases, it can causes issues when trying to process payments
that are being process by the payment polling page after returning
from the payment acquirer.
To avoid this concurrency issues, the cron will only process payments
that have been validated for at least 10 minutes.
closesodoo/odoo#29317
- When resending a failed mail the code could crash.
The issue is caused by the fact that calling `_get_recipient_data`
with the parameter `pids` only, returns as the partners' groups the
value `None`.
The codes that uses the result of this method consider the groups as
an iterable and crash when trying to iterate on a `NoneType`.
OPW-1916498
closesodoo/odoo#29408
- When a payment is done through a `payment.transaction` the
communication should be the transaction's reference instead of its
invoices reference.
closesodoo/odoo#29187
- When installing account using a request (e.g. http route auth set to `None`) not bound to a database,
the installation fails.
To avoid this, we check if the request we are using is bound to a
database, if not, the fallback code is executed.
- Before this commit when a transaction failed, the code doesn't
rollback and continue to process the other transaction, thus creating
record that should be rollbacked.
closesodoo/odoo#28748
- In some cases (record rules modified to allow access to multi company
SO) the duplication of a quotation isn't possible if the quotation is
set on a company than the user trying to duplicate it.
This is due to a computed field that tries to access the order's
company currency.
closesodoo/odoo#28945
- On `project.task` records the field `allow_timesheets` is a related
set to `readonly=False` which triggers writes on `project.project` and
raise access rights issue for users who can create tasks but cannot
write on `project.project`.
OPW-1910877
closesodoo/odoo#28943
- This commit fixes a crash that happens when the server receive a
JSON-P call done in two requests (a POST followed by a GET).
The issue is due to the fact that when the first request is done (POST
one) the member `params` is never initialized.
This parameter is then used in the module `auth_signup` on an override
of the method `dispatch` thus crashing the code.
To avoid the crash, we now initialize `params`.
closesodoo/odoo#27369
- The value returned by the method `_portal_ensure_token` is False due
to a cache issue.
The value is generated written using the `sudo` environment while in
the current user environment the cached value is `False`.
After generating the value, the cache is not cleared, thus letting the
method return `False`
closesodoo/odoo#28836
- This commit prevent to send notifications to inactive users.
- This fixes a bug where two partners have been merged and one of its
users is archived.
If one of the two users is inactive the code might use its `notification
type` preferences instead of the active user's one.
closesodoo/odoo#28730
- When computing the count of quotations count and the invoiced amount
on a mass mailing, we do not check if the current user has access to
the models `sale.order` and `account.invoice.report`.
This fix first check the access rights on the models, if the current
user doesn't have read access, then we set the computed value to 0.
closesodoo/odoo#28717
- If the `internal` field/column on the message subtypes (table: `mail_message_subtype`) is set to null instead of false in the
database, the notifications to the followers are not sent by mail.
closesodoo/odoo#28699
- When creating an eCommerce cart using the Public User, the code tries
to access all the sale orders linked to it.
Depending on the count of sale orders linked to the partner, the
loading can take a lot of time.
To avoid this, we only search for the sale orders of connected users
and we only retrieve the last one.
- When deleting attachments, the foreign key constraints on
`message_main_attachment_id` are triggered which could take
a lot of time to be computed.
closesodoo/odoo#28358
- The field `signup_valid` was computed and stored using the `superuser`
env, which causes issue since it means the value was computed for the
wrong environment.
Using a compute_sudo instead of manually calling `sudo()` fixes the
issue.
e.g: reading signup_valid using a regular user (non superuser) will
always return False, while doing it as the superuser will return
the correct value.
- When fetching messages (e.g. opening discuss), we do not check if the
model associated to a message is accessible for the current user.
This could result to access rights error messages when trying to read the
main attachment of the associated record.
To avoid to triggers this errors, we first check if the current user
has read access to the specific model, if so we try to read the
record's main attachment.
closesodoo/odoo#29025
This commit aims to improve the user experience when using payment acquirers. There currently are no error feedback with some acquirers, which leaves the user wondering what is going on and what is the real status of its payment.
In some cases, the user is currently being redirected to the home page even though the payment has failed. We want to make it more obvious to the user that something unexpected has happened by redirecting to an intermediate page that will provide good feedback on payments status.
Another goal of this commit is to order acquirers by sequence instead of by flow and to select the first acquirer by default. This feature was already implmented in commit fe294fd43e521bd2d339e962f43acf46c3d4cb97, some UI adaptations were needed though.
Related to task #36680Closes#26958
- When receiving a 3DS payment notification from Ingenico the payment
transaction should be set to "pending" and not in "done".
Then a second notification is send by Ingenico to set the
payment.transaction to "done".
This is the reason for accepting "pending" as a valid state on the
feedback validation.
- When checking if a recipient has already received a mass mailing, the
record model for the recipient was not checked.
Which leads to false positives.
When we get the existing tags to append them a new id, we don't get a
list of id but a list of tuple with one id, this only append if you have
more than one accounting of these country installed, as the first time
it will return an empty list. So the command sent to the ORM, is not
built correctly.
To fix this we just append commands '4' that will be append in a list.
- We extract some code logic to methods to allow to override them.
This is needed for the subscription module where a payment token need
to be copied from a transaction to a subscription.
The subscriptions is created from a sale order and before the
payment.transaction holding the payment.token id is validated.
Since the payment.transaction is not validated, the subscription
module doesn't find the correct transaction.
By extracting this code logic, we can override exactly when it should
be.
- When creating a transaction on the payment page of the portal, the
transaction reference returned was incorrect.
This commit return the newly created transaction's reference.
- The method to compute the reference of a payment.transaction and avoid
duplicate was missing some edge cases (for example if there was a '-'
in the reference).
- The creation of transactions in the route /website_payment/pay was not
checking for duplicate payment.transaction.
- When creating an invoice created after a payment, we need to force the
company to the transaction's company.
This avoid to create move lines with different companies (Administrator's
company because of the payment processing done by the admin and the
sale order/transaction company).
- When a tracked field is modified, a mail.message is created.
When create is called its tries to fill missing values with "default
values".
It first tries to find the default values in the context, which may
occurs.
For example, modifying a tracked field on a subtask will add a key
"default_parent_id" in the context, which is the parent_id of the project.task.
Create will try to use "default_parent_id" for the mail.message
parent_id field, which make the SQL Request invalid.
- When trying to fetch notifications for failed mail delivery, the code
doesn't check if the partner is active or not.
If the partner is archived, then it tries to access its information on
a dict that doesn't contains them and crashes.
- Before this commit, a sale order that generate a subscription and paid
by the form method do not create a payment.token.
After this commit, we check if the sale order need a payment.token to
be created, if so we set the correct transaction type.
Toufik Ben Jaa