When creating a mail for a user in an other company then the
record, the "send" button fails with a traceback because on
specific template try to access the company.id of the user
which is not accessible due to the access controle.
This PR fixes the problem by sudoing the access to company id.
The mail now sends without problem.
Step to reproduce:
1. Use two companies (comp1 and comp2)
2. Use 3 users (user1, user2, user3)
3. Be sure every user has a confirmed account
4. Change the users to set both company as allowed.
5. Set the current company of the users as follow:
user1: comp1
user2: comp2
user3: comp2
6. Install the project module
7. In `settings > security > record rules`, archive the rules named:
- `Project: multiple-company`
- `Project/Task: multiple-company`
- `user rule`
8. Using user1, create a new project and a new task.
9. Using user2, go to `Project module > Search`, remove `My tasks` filter,
select the task created by user1, in the chatter add user3 as follower.
10. Send the mail => access error.
The `AccessError` is due to user2 trying to access comp1, in particular
`company.name`.
By adding a `sudo`, we also make sure that the template rendering won't
fail bacause of a similar `AccessError`.
opw-1907844
closesodoo/odoo#28710
Define a x2m tree view with a default_sort including more than 1 field to order the list against
Before this commit, the second field was never used
After this commit, it is used
OPW 1909785
closesodoo/odoo#28840
When opening the Manual Reconciliation widget, all partners with opened
invoices and payments are fetched.
In some cases, the database might contain a lot of partners without any
reconciliation suggestion; therefore, the partners with suggestions are
'lost' in the view.
This commit sorts the data: we first display the parters with a
suggestion, then the others. This should improve the usability of the
view.
opw-1903575
closesodoo/odoo#28958
Consider a many2one field `foo_id` on model `bar`, with an inverse one2many
field `bar_ids` on model `foo`. During an onchange, the statement
bar.foo_id = foo
puts a special value in cache to add `bar` to the value of `foo.bar_ids`
without explicitly reading `foo.bar_ids`.
Executing the above statement a second time, the cache of `foo.bar_ids` is no
longer empty. This causes the actual value of `foo.bar_ids` to be read and
updated. The issue is that this can be slow for large values of `foo.bar_ids`.
Avoid reading the value of the one2many field by handling the case where the
cache contains the special value: simply update the special value to take into
account the second assignment.
closesodoo/odoo#28982
Embedding a video can't work because it embeds an iframe, which is not supported
by most email clients for security reasons.
(What happens when Gmail shows embedded videos in displayed emails, is that you
send a link in the email body, and it is at rendering that Gmail adds the iframe
into the page.)
So the bugfix solution is to hide the button.
Since there is an option "res_model" that allows us to know when we are in that
case, we remove the video option.
opw 1905497
closesodoo/odoo#28911
In the case of calculating payroll, we don't want to convert the
datetimes using the timezone of the user as we really want to see what
the employee has done from one date to another (usually from the start of
the month to end of the month)
Closes#26256closesodoo/odoo#28977
Fine-tuning of commit: o50f77ba091189bd785d459c042a6cec04a125fdb
When costing is in FIFO mode, product price can be updated whereas the current
user doesn't have the right to modify the products.
It therefore introduced a sudo() to make this computation;
however since this is modifying a company-dependent field,
a force_company was missing to update the correct one.
Closes#28487
opw 1907377
closesodoo/odoo#28662
This commit extend commit https://github.com/odoo/odoo/commit/ef48b81ab127dd717a4a9d106edd5c51121bc8f7
When you have a cart on multiple session and confirm the card in one of them,
you could still access your cart from other session (note that you could not do
anything with it as it would be reset when adding product or changing qty).
Closes#28210
This reverts commit 08b2d1f9ac and the
subsequent commit a75533daf2be325e059f0d4badfb0cf3a2f7590f, because they
caused more problems than they solved.
Not only did we get issues with missing footers in some cases, but the
address box also gets misplaced on the left in many layouts.
See #31184, #31533, #31531
See opw-1925894 (reason for patch), opw-1948160 and similar ones (regressions)
Closes#31626
Before this commit, when hovering on a email icon of a message
in chatter without any customer email data, there was a crash
with the following error message:
"No enumerator given to foreach"
This was caused by `undefined` being passed to `t-foreach` when
there are no customer email data on the message. Since
`undefined == null`, it raised the error above.
closesodoo/odoo#31587
Signed-off-by: =?utf-8?b?QWxleGFuZHJlIEvDvGhuIChha3Up?= <aku@odoo.com>
`this._id` is overriden by the crosstab_bus, so the event handlers
weren't unbound at destroy.
closesodoo/odoo#31578
Signed-off-by: "Aaron Bohy (aab)" <aab@odoo.com>
Together d60f2ab0e2 and
24ca67b545
corrected the triggering of automated actions at *each* recompute of a field
It is problematic since, maybe, the field that should trigger an action
*is* a computed one. It often happens with "state"-like fields
This commit aims at applying the logic of those two commits,
except in the case we do want the action to be triggered
even in a recompute case
OPW 1935727
closesodoo/odoo#31422
Signed-off-by: "Lucas Perais (lpe)" <lpe@odoo.com>
On some chart of accounts, some records (e.g. account.tax on l10n_be) have
children and some are deactivated when the chart of account is created.
The children on the account.tax and templates were not created in the same order
The deactivated records were not found in the search.
Before this commit the translations did not match the right record on the
account.tax (e.g. 21% tax translated with a 12% name in Dutch)
Bug noticed with avw
closesodoo/odoo#31510
Signed-off-by: "Martin Trigaux (mat)" <mat@odoo.com>
When creating a portal user from the User & Companies menu in the
Settings.
Before this commit, the created user had both groups' portal user and
internal user, which generated an error in the display of the user
accesses and rights. This also occurred if we manually add a portal
user to the internal user group.
Now, when creating a portal user, the user only has this group. Also,
if we manually add a portal user to the internal user group, an error
is raised to inform that only one user type is allowed.
OPW-1929367
closesodoo/odoo#30958
Signed-off-by: "Lucas Perais (lpe)" <lpe@odoo.com>
This commit add a default barcode on locations automatically
created once a new warehouse is created (stock, input, output, ...)
Task : 1939268
closesodoo/odoo#31000
Signed-off-by: "Simon Lejeune (sle)" <sle@openerp.com>
08b2d1f9ac was intended so margin on the top of the body worked (it
seems that wkhtmtopdf only started the body from the first visible
elements).
From a subsequent report, on some document template the CSS could have
adverse effect of not showing the footer.
With this changeset, the CSS is only applied on the body which was the
first intention.
fixes#31531
opw-1925894
closes#31533
Set the invoice policy to "ordered".
Then you can set to true the parameter "automatic_invoice", along with choosing
a mail template.
If you then set the invoice policy to "delivered",
"automatic_invoice" is rendered invisible.
However its value is not changed, so it is possible to have it set to true,
while the invoice policy is set to "delivered".
We change the parameter when settings are saved.
opw 1940641
closesodoo/odoo#31524
When confirming purchase orders with a lot of lines the performance
is very slow (sometimes reaches the memory limit). Creating the stock
moves in only a multiple create ameliorates the performance.
opw 1929276
closesodoo/odoo#31471
Commit fcb972d skipped a test on saas-12.2 after forward port as it was not
working on that version.
This commit restore the test and fix it.
It was actually a race condition on the save step on edit mode.
Something similar was done already for another test, see 74a98ea.
closesodoo/odoo#31465
When a blocking message is configured on a product, we force the removal
of the `product_id` on the SO line. This causes a problem in method
`_get_display_price`. When the pricelist is configured with
`discount_policy != with_discount`, `get_product_price_rule` is called
with an empty `self.product_id`.
We move the `product_id` removal at the end of the onchange.
opw-1934386
closesodoo/odoo#31456
With the BS4 update, a traceback occured when clicking on a m2m tag using colors
in a list view.
When using colors on m2m tags, the badge was wrapped inside a `dropdown-toggle`.
However, there is no `dropdown-menu` by default (it is only rendered in FormFieldMany2ManyTags
when clicking on the `.dropdown-toggle`, hence the traceback.
The `dropdown-toggle` class is now only set if necessary.
Task 1925313
closesodoo/odoo#31445
- Activate 'Multiple prices per product'
- Create a Product A, and add an entry in the 'Pricing' section of the
product form
- Create a SO, a product, and add A in the 'Optional Products' tab.
- Click on 'Add to order lines'
A crash occurs at currency conversion.
When getting the conversion rate, the company is empty in method
`_get_conversion_rate`. This is because the company is a stored related
field, which is computed after creation. However, the method
`_prepare_add_missing_fields` is called before creation. This method
calls several onchange methods, one of them computing a price
conversion.
We explicitly add the company when creating the SO line.
opw-1939106
closesodoo/odoo#31455
- Create a product with variants
- Create a BOM for this product
- Add a component, specify a variant in 'Apply on Variant'
- Change the product of the BOM
The 'Apply on Variant' fields remain filled, although it doesn't apply
anymore to the new product.
opw-1943918
closesodoo/odoo#31435
In some special instance, a mention could get linked and the user would
not really be linked.
This is because of a difference between linking the mention and adding
the user as follower that required a space after the mention.
With this change:
- `[adding mention]@admin [backspace].`: was linked but not added as
follower => now it is not linked either.
- `[adding mention]@admin [backspace][enter][adding mention]@admin `:
the first @admin was linked => now the second is linked
Without the change, added test fails with:
"should not contain a link in the message content"
"should not have linked mention without space"
opw-1934946
closes#31433
The SSF would properly mark its own records as deleted, but it would
not properly handle deletion requests coming from an onchange, and it
would not necessarily convert DELETE_ALL commands (5) into the proper
sequence of individual (2)s matching existing records.
closesodoo/odoo#31431
Before this commit, we used dict keys before they existed
And made the share button crash
After this commit, there is no crash
OPW 1943301
closesodoo/odoo#31427
The margin-top/margin-bottom on a address on the top of the report does
not work because:
- display flex on an address in wkhtmltopdf is not perfectly implemented
and seems to remove vertical margin
- margin-top on the page first visible element is removed
To fix this issue, this code remove the display:flex on the address
widget and add an empty "visible" element at the start of pages.
opw-1925894
closes#31184
Before this commit, the template that was rendered when sending
an email to a customer to invite hime to pay online
was not translatable
This was because the override of the template did not have an xml_id
After this commit, it is translatable
OPW 1944258
closesodoo/odoo#31396
When the currency used for a payment/internal transfert is not the same
as the company currency, the prices shown in the reconciliation
suggestions are computed using the company currency.
1) Enable multi-currency.
2) Setup two bank, one in USD, the other in EUR.
3) Leave the company currency to USD.
4) Create an invoice for a partner targeting the EUR bank and
validate it.
5) Create a bank statement for the EUR bank amounting the **exact**
value of the invoice for the **same** partner and reconcile it,
this will create the payment behind the hood.
6) In the reconciliation the invoice appears as suggestion, if the
currency symbol is correct, the amount is shown as USD.
opw-1937202
closes#30623closesodoo/odoo#31290
Have an editable list that begins with a date/time field
create a line.
The first field is focused and the datetimepicker is popped up
Now, stroke ESC key
Before this commit, there was a traceback because the datetimepicker received an erroneous
BLUR/INPUT event
After this commit, there is no traceback as we detroy the widgets of the line
(including the datetimepicker) before removing the row from the DOM
OPW 1932409
closesodoo/odoo#31342
For a translated field with a callable method (e.g. xml_translate), when
modifying the value of this field in another language than en_US, the master
version was lost.
Before this patch:
>>> record.arch = "<h1>Title</h1>"
>>> record.with_context(lang='fr_FR').arch = "<h1>Titre</h1>"
>>> record.with_context(lang='fr_FR').arch
"<h1>Titre</h1>"
>>> record.arch
"<h1>Titre</h1>" # lost English version
After this patch:
>>> record.arch = "<h1>Title</h1>"
>>> record.with_context(lang='fr_FR').arch = "<h1>Titre</h1>"
>>> record.with_context(lang='fr_FR').arch
"<h1>Title</h1>" # write had no effect
>>> record.arch
"<h1>Title</h1>"
When modifying a translated HTML field in English, a matching to detect the
difference and avoid losing the translations is done.
This is not supported for update in another language.
The main reason is the difficulty to detect changes in the architecture.
To update translations, the supported way is to go to the list of translations
and update them there.
Before this patch, the given value in another language was given to the SQL
query and made an update in database:
if single_lang or not (has_translation and field.translate is True)
-> True or not (True and False) -> True
If a field is callable, it should also be ignored, the same way than
translate=True fields
opw-1887162
closesodoo/odoo#31330
Let users A, B be in in companies C1 and C2,
such that A is currently in C1 and B in C2.
User A tries to assign to B an activity on record R belonging to C1.
It fails because at the time of the check B is not in the correct company,
even if B could handle the activity after switching company.
The _check_access_assignation was added in commit 96a223a5f0,
to avoid activities to be created for records that the target user can't read.
Previous use-case is a legitimate one where we want to bypass this restriction.
Note that the systray notification widget is not company dependent,
and there is no way to remove a notification on a record the user can't read.*
In case where the record is company dependent and on a different company,
we skip the record rules check.
It is assumed that the check would fail because or company-related record rules.
It will create some unwanted activities, but only the minimal number we can let
through while allowing for all legitimate flows.
*Better solution for master is to give the user some more explicit message
if reading the record, suggesting to switch company,
or to allow to dismiss the notification altogether.
opw 1933862
closesodoo/odoo#30810
Have a SO; accepted and signed; and the client choose to pay with wire
transfer.
Before this commit, the transfer's transaction is never updated to 'done'.
Even after the invoice is created and the payment is encoded and
reconciled. The client will continue to see the pending message.
Now, when the SO is confirmed, the transfer's transaction is set to 'done'.
The client will see the done message.
opw-1935516
closesodoo/odoo#31352
Before this commit, it was impossible to search anything in the list view
when doing a Inventory Valuation > Current Inventory
After this commit, a few meaningful fields are searchable
OPW 1943676
closesodoo/odoo#31356