The cache is quite time critical, as it is accessed millions times when reading
multiple fields on hundred of thousands of records.
Avoiding indirections and `if` statement when possible speeds up the cache
access time.
- 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
- Install a second language, e.g. French
- Set Parter A language to French
- Create an invoice for A with a date due in the past
- On the partner form view, print the 'Due Payments'
The body of the letter is not translated in French.
Something quite weird appears:
- The corresponding string is exported in the `stock` module
- It is linked to the demo data `stock.res_company_1`, which corresponds
to 'My Company, Chicago'.
Therefore, the translation cannot be found by the corresponding query
generated in `_generate_translated_field` and `_read_from_database`:
```
SELECT "res_company"."id" as "id",COALESCE("res_company__overdue_msg"."value", "res_company"."overdue_msg") as "overdue_msg" FROM "res_company" LEFT JOIN
(SELECT DISTINCT ON (res_id) res_id, value
FROM "ir_translation"
WHERE name='res.company,overdue_msg' AND lang='fr_BE' AND value!=''
ORDER BY res_id, id DESC)
as "res_company__overdue_msg" ON ("res_company"."id" = "res_company__overdue_msg"."res_id")
WHERE "res_company".id = 1 ORDER BY "res_company"."sequence" ,"res_company"."name"
```
Indeed, `res_company.id` is 1, while `res_company__overdue_msg.res_id`
is 3.
The root cause has been solved in v11, to we only export the necessary
term.
opw-1908337
closesodoo/odoo#29525
After this fix, the field `partner.street` is correcly rendered,
but as the test shows the `street_name` and `street_number` fields
are not correct.
But as there are tests that validate that wrong use case, I
consider it a *feature* and not a bug.
opw-1896773
closesodoo/odoo#29520
- Buy on product on the eCommerce with a partner having a single address
- At address selection, edit the shipping address
The billing address is also modified.
From the Odoo PoV, this is expected since they point to the same
partner. But from a user PoV, this is totally unexpected and confusing.
Therefore, we only allow the edition of the shipping addresses which are
different from the billing address. Yet, if the user modifies the
billing address, it will change the corresponding shipping address as
well. However, the usual flow is to set the billing address, then the
shipping address. So that should cause less issues. In v12, a warning
message is added.
opw-1914185
closesodoo/odoo#29509
opw-1916148
The city, state and zip code are shown behind the street name and
street number, and not in a new line.
This only occurs in the read-only view.
This was changed to use the field 'street', which is a text of the
street name, number and door number in the street formatted in the
format of the partner's country. This only for the read-only view,
leaving the 3 fields separated for the edit.
closesodoo/odoo#29467
If the price section goes on two lines because of crossed
prices or many icons, then it would overlap with the product title.
See before/after on the PR.
opw 1913521
closesodoo/odoo#29388
Commit 5804246e0f introduced some improvements to speed up performances.
One of them was to check if a customize_show view was active or not but the
condition was on view.customize_show instead of view.active.
Thus, as that view is always a customize_show, the condition would always be
met.
closesodoo/odoo#29414
The visibility condition of the Matching group on account move line
was not compatible with the visibility condition of the
"View partially reconciled" button. So the group being hidden was
hiding the button that should overwise have been visible.
closes#32043closes#32216
opw:1961210
closesodoo/odoo#32371
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- 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 definition of `attachment_ids` on model `email_template.preview` is wrong,
because its table/columns refer to the model `mail.template`. As the field is
only used to preview a result in a wizard form, it does not need to be stored.
closesodoo/odoo#29349
used to fetch debit & credit recorded in Tax Cash Basis Journal Entries
Main
-
By allowing to change the `amount_mnt` var we will be able to change the
values recorded in Tax Cash Basis Journal Entries, i.e, debit & credit
values.
Explanation
-
We want to keep the `amount` just the way it has been computed because
that is right. We don't want to change that.
Our issue is the`rounded_amt` which is the value that is passed to the
debit and credit downwards.
We have only hooked a new method to allow us later inherit that method
and make our own computations regarding the `rounded_amt` which is the
main subject of this PR and later pass it down to the debit & credit
fields as need for localizations that could be facing the problem of
having the computation of taxes at date of invoicing instead of date of
payment.
`amount` var is used here:
`
'amount_currency': self.amount_currency and
line.currency_id.round(-line.amount_currency * amount / line.balance) or
0.0,`
and we are not intending to change that because the value written to the
`amount_currency` field is right.
What we intend is to compute the values for debit and credit fields
which were computed in this method at invoice date, some l18n need them
at payment date, e.g, l18n_mx.
Be aware
-
Do not be mislead by the fact that `rounded_amt` var is the one taken to
do those computations. It is just a mean to the final goal. Rounding is
not an issue and has never been.
Background
-
By allowing this merge to flow we will be able to address the following issues:
https://github.com/odoo/odoo/issues/25057https://github.com/odoo/odoo/pull/17196https://github.com/odoo/odoo/issues/9972
Final Goal
-
Being able to perform the computation of the debits and credits
according to l10n_mx in odoo/enterprise#3137closesodoo/odoo#28991
When activating a filter on a list view,
the environment of the action contained a context with an orderedBy key
which was then used by every controller and model in the various
parallel flows, i.e. changing actions
After this commit, we prevent it by excluding the key when executing an action
OPW 1913190, 1914019
closes#29190
required: [('chart_template_id','!=',False)] doesn't work because you need to fill the chart_template_id
to install a chart of accounts for your company. Then, the transfer_account becomes required before its installation
and then, you are not able to install a chart of accounts for your company.
If installed along with `auth_signup`, it sends an email when creating a missing user authenticated through LDAP.
It is a confusing message that makes no sense, because the user is, from his POV, not actually creating a new user, but just authenticating with a new app with his known company-wide credentials.
Besides, that invitation leads the user to change his password in Odoo, although he probably doesn't want to do that and have a password for Odoo and another in the LDAP server.
The best option is to disable that email completely, which is what this commit does.
closesodoo/odoo#29243
The module `vatnumber` (which is not maintained anymore) uses an
incorrect validation method for Albanian VAT numbers. Therefore, we use
the library `stdnum`, on which `vatnumber` relies for most cases.
opw-1912680
closesodoo/odoo#29280
When using limit=1, PostgreSQL sometimes use sub-optimal plan like
"Index Scan Backward using xxx". To avoid this, adding a fake sort
will make PostgreSQL to use the same plan as without limit, and in
this particular case, the index on message_id
closesodoo/odoo#29278
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The field "date_planned_finished" was not computed when changing the fields
"date_planned_start" or "duration_expected".
opw:2048416
closesodoo/odoo#35537
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Set a language using RTL (e.g. Arabic)
- Activate mobile mode (through debug mode or on a mobile device)
- Go to the CRM kanban view (make sure no record exist so the no_content
message is displayed)
- Add a new record
- Fill in the name, click outside of the field
The no_content message is displayed over the form view and it is impossible
to save the record.
The root cause is the incorrect structure of the kanban view page in RTL,
leading the user to the wrong element and triggering the wrong event.
We make the structure of the view aware of the RTL configuration.
opw-2046231
closesodoo/odoo#35509
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
- Set a language using RTL (e.g. Arabic)
- Activate mobile mode (through debug mode or on a mobile device)
- Go to a grouped kanban view (e.g. CRM pipeline)
- Swipe to the left
The column to the left if shown instead of the column to the right.
In RTL, the kanban groups order are inverted. Therefore, we also need to
invert the swipe direction.
Before this commit, when a user imports an Excel file, with date as
strings. The _try_match_date_time function will try to find the best
date parsing to use in the import without taking into account the
language of the user.
Now, the function will take into account the language of the user when
trying to find the best date parsing pattern for the import.
opw-2046217
closesodoo/odoo#35540
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Sales > Configuration > Products
was present twice
Move to sale.prod_config_main and remove menu_product_settings in master
closesodoo/odoo#35159
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Denis Ledoux