Keep the manifests as light as possible, to easily see custom behavior/content.
Complete the work of previous commits cleaning the manifests content:
* 42bad1a6d2
* ef7005f524
and make sure this kind of cleanup commit is not necessary in the future
because it is now automatically verified by a dedicated test.
closesodoo/odoo#107735
Related: odoo/enterprise#34903
Signed-off-by: Julien Castiaux <juc@odoo.com>
To Reproduce
============
- on a db with sales, website and Stripe payment aquirer activated
- on the portal of a user add two payment methods, an expired card
and a valid one
- create a SO and generate its payment link
- try to pay with the invalid card first -> and error (card was declined)
- try to pay with the valid card -> error (same idempotency key)
Problem
=======
the generation of the idempotency key is based only on dbuuid, transaction's
reference and the scope. So in this use case it will generate the same key.
Solution
========
The idempotency key prevents issues where the customer is charged twice for
the same thing. In this case, we don't want to prevent anything since the
customer is on the page. It's suggested to use idempotency keys only for offline
payment when the customer is not in front of the payment page (e.g. when the cron
charges the customer for his subscription)
opw-3091354
closesodoo/odoo#108163
X-original-commit: 089387087010ae917494d5072f00d72c572b7d09
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
Prevent the editor to inserting html during pasting or dropping
in editable zone that will not support the html content received.
task-2990147
closesodoo/odoo#108162
X-original-commit: 107ebb1db00a4f5a0fc6f64b76f00b040310e432
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The URLs in notes created from the systray were not transformed into links.
This solves the problem.
Task-3052952
closesodoo/odoo#108147
X-original-commit: 00fbfab9b7dedc2b5917e7807d8abd2995253919
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- generate password reset link
- access the link
- the page redirects to login
Bug:
password reset and new account creation share the same path
this commit [1] made it so when you click on the new account link after
it was activated you are redirected to login
Fix:
the distinction between both scenarios is made using the presence of
'signup_email' in the query.
only add signup_email when creating a new account
opw-3068790
[1]:https://github.com/odoo/odoo/commit/97658791306349456761ba4c18d504f861e3bb98closesodoo/odoo#108093
X-original-commit: 3ba02fbeb54afc0ebd5ab434cdf921159646e9d0
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Issue:
- clicking on various account field gives traceback because
of invalid domain.
Cause:
- https://github.com/odoo/odoo/pull/105131 PR remove a leaf
from account domain but forgot to remove '&' operator.
Fix:
- removes '&' operator from account domain.
task-3099758
closesodoo/odoo#107914
Signed-off-by: John Laterre (jol) <jol@odoo.com>
On clicking "add to cart" button, there is a simple animation of product image
moving to the cart icon. However, if the cart icon is hidden because of disabled
option "Show Empty Cart", the animation is broken: the image is moving to left
corner of the navbar.
Fix it by showing cart icon before starting the animation.
opw-3078396
closesodoo/odoo#107760
X-original-commit: 6110b993ce63356e1b5b900f7bacb2afa648f6ad
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
For a lot of clients, the number of quotations is big, and canceling
them one by one is time-consuming.
task-2991744
closesodoo/odoo#104531
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
install l10n_ph module and open any vendor bill, click on action button and click Download BIR 2307 XLS, in the opening wizard, the one2many field moves_to_export is not aligned well in the form due to missing colspan and currently the field is too compact in the form.
closesodoo/odoo#108094
X-original-commit: 53ffdccc0310c32980297d5dcc3f6a24fa852a8c
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
This commit adds the avatar widget to the responsible
field in the event form view.
Task-3100951
closesodoo/odoo#107927
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Prior to this commit, the layout of the settings in the kanban card was
broken
closesodoo/odoo#107895
X-original-commit: 922029c2197145d555b65becd7210c4d7a13d439
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Since this commit [1], the "avatar" image of the logged user is no
longer displayed on the "boxed" header template.
This is due to the "t-nocache" attribute which was forgotten for the
"_avatar" parameter in the "user_dropdown" template.
[1]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466d
task-3063878
closesodoo/odoo#107861
X-original-commit: 484f0acade527e38e9569fc066b4647a8d70e397
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
The field was not taking the full size it was allowed to, hence it was
not possible to write the content.
task-3087717
closesodoo/odoo#108102
X-original-commit: eefdd43b24cc4edc0ea9167f1f017c3297c83d21
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Sometimes, there is a crash when uploading a file when loading an article for
the first time.
Impacted versions:
16.0+
How to reproduce:
- open the odoo home page (module menu) and CTRL+f5 (force reload)
- go to the knowledge app
- switch to another article than the first loaded one
- in that article, put the cursor somewhere and type ENTER to create a new line
- type the /file command in that line
- try to upload a file
- traceback (if it does not happen, try again from the first step, it is not
always consistent)
Explanation:
html_field onWillUpdateProps was using the wrong "new" values to update the
currentEditingValue, which sometimes induced a rerendering of the html_field
during a 'blur' event when it should not have (because it seemed that the value
had changed when it did not), which could cause a crash when it occured after
the editor saved nodes with `preserveCursor` to recover the cursor position.
(i.e. when opening the mediaDialog to upload/select a file for insertion in the
editor).
Task-3086694
closesodoo/odoo#108125
X-original-commit: fc9ac0bec8377a2804892cdfe07629c44283c679
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Abeloos Damien (abd) <abd@odoo.com>
Removed annoying error raised onchange of the date/name if they don't match anymore. This was done during the update, which was dumb since it was popping in case you wanted to change both the date and the name. It now only relies on the constraint that is verified upon posting the invoice. Onchange warning is kept only for the format change.
Ensure the date constraint is always verified no matter if the invoice was already posted before, or if we're in quick edit mode: the date's info located in the name must always match the accounting date. This is ensured when posted.
task-2976499
closesodoo/odoo#108116
Forward-port-of: odoo/odoo#107867
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- edit some text on the website
- select a part of the text then press (alt+s)
Bug:
the selected text is deleted before the save
Fix:
if "alt" key is pressed don't execute the editor listener
(except for Mac OS)
opw-2996264
closesodoo/odoo#108103
X-original-commit: 1cd0b4396699513c80bafc2f052d373f9ef9f55e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
The currency field shows as a badly aligned "in USD".
This PR adds a proper handling of the combinations
of accounting and multi_currency groups.
Original PR in v15: https://github.com/odoo/odoo/pull/104013closesodoo/odoo#108101
X-original-commit: d2363794411bbc9147b8ff0d519d588a3814e582
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Before this commit, the JS Framework receives different types of modifiers:
- List: used for domains.
- String: used for the dynamic domains and boolean values ('1' or '0');
- Integer: used for boolean values (1 or 0);
- Boolean: used for boolean values (True or False);
The issue with this, is that the JS Framework needed to manage the 3
different possibles ways to have a boolean modifier (1, '1', True).
Now, only three types are sent to the JS Framework:
- List: used for domains.
- String: used for the dynamic domains and boolean values ('1' or '0');
- Boolean: used for boolean values (True or False).
The boolean usually sent in a Number (1 or 0) will be transformed into
proper Boolean types (True or False).\
Note that, the 'falsy' modifiers are not sent to the JS Framework.
closesodoo/odoo#108095
X-original-commit: faddb53f30b94ac47ffd7b3b1af36f094f3a60f6
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
After this commit, the transpiler will add the dependencies of a file
to the second argument of the odoo.define(...).
For example:
odoo.define("@test/test", ['@test/dep1', '@test/dep2'], async function (require)
With this change, the code for the module system in the browser will get
directly the dependencies instead of having to stringify the function
defining a module, and grep inside for the "require" words.
closesodoo/odoo#105651
Taskid: 3062390
Related: odoo/enterprise#34895
Signed-off-by: Géry Debongnie <ged@odoo.com>
- Before this commit
Keyboard navigation in dropdowns lead to a traceback
- Explanation
The traceback happens in the bootstrap library.
When upgrading to bootstrap v5.1.3 (see c48f57e), a fix done in the
previous bootstrap version was lost (see 78f85f2).
This previous fix also added a test but it was not enough to
detect the issue when the bootstrap lib was upgraded.
- After this commit
This commit reintroduce the same previous fix and adapts the test,
hoping it would be enough for future changes to not break further
the expected behavior.
closesodoo/odoo#108080
X-original-commit: daca8fe4e3da4a5ad5fabf3730496a3919af8abc
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
An option to disable the automatic wrapping of inline nodes into p at
editable root is needed by Studio's report editor.
task #2995601closesodoo/odoo#108068
X-original-commit: 9cae999d413a71f3591fcbbadeefea1509778c76
Related: odoo/enterprise#35013
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: base_setup, hr_timesheet, mail, partner_autocomplete, web_tour
Start odoo without -d and with a --dbfilter that allows multiple
databases. Via JSON-RPC access the /web/session/authenticate route
providing a non-filtered database and valid credentials. Traceback,
`request.env` is None.
Since httpocalypse the initialization of the ORM (cursor, registry,
environment) is greedy. It means that the connection to the database is
established very early during the request routing or skip altogether in
case no dbname was known at that time. This contrast with prepocalypse
where the various ORM thingies were lazily setup the first time they
were accessed.
This changement has an important implication regarding authentication.
In prepocalypse, thanks to the lazy approache, a cursor/registry/env
would be setup on the database you just login upon using the
`request.env` for the first time. This was very nice in this regard but
had other problems.
Since httpocalypse such operation is no more possible. Devs must
initialize and use their own cursor/registry/env in case they
authenticate on another database than the one `request.cr` is (maybe)
connected to.
The `/web/session/authenticate` controller is an example of such case.
It crates its own cr/registry/environment after authentication. The
problem the controller uses `ir.http.session_info` and that not all
overrides were updated to use `self.env` (=the env created in the web
controller) instead of `request.env` (=the missing env of the request).
closesodoo/odoo#108063
X-original-commit: 7b9bd9d37731fae724dc5d91da656dab70aa9ad4
Related: odoo/enterprise#35012
Signed-off-by: Julien Castiaux <juc@odoo.com>
The main goal is to reduce the processing time
it takes for views to be validated during installation.
In order to mimic the behavior of the view creations
during installation, and to analyze the performance,
I used the below code in the shell:
```py
env.cr.rollback()
domain = [('model', '=', 'res.config.settings')]
views = self.env['ir.ui.view'].search_read(domain, [
'id', 'active', 'arch', 'inherit_id', 'key', 'mode', 'model', 'priority', 'type', 'xml_id'
], order="id ASC")
for view in views:
if view['inherit_id']:
view['inherit_id'] = self.env['ir.ui.view'].browse(view['inherit_id'][0]).xml_id
self.env['ir.ui.view'].browse(reversed([view['id'] for view in views])).unlink()
with odoo.tools.profiler.Profiler():
for view in views:
new_view = self.env['ir.ui.view'].create({
key: self.env.ref(value).id if key in ['inherit_id'] and value else value
for key, value in view.items()
if key not in ['id', 'xml_id']
})
if view['xml_id']:
module, name = view['xml_id'].split('.')
self.env['ir.model.data'].create({
'module': module,
'name': name,
'model': 'ir.ui.view',
'res_id': new_view.id,
})
env.cr.rollback()
```
Using the above, and analyzing the speedscope profile,
we can see the lines
```py
action = self.env['ir.actions.actions'].browse(action_id).exists()
```
from `_validate_tag_button`, and
```py
if not self.env['ir.model.data']._xmlid_to_res_id(group.strip(), raise_if_not_found=False):
```
from `_validate_attrs`
take a significant time.
Batching them the actions and groups existence
(as recommended as further improvement in the comment which is deleted by this revision),
as well as a more efficient algorithm for `_get_node_groups`,
reduce the processing time of the views validation.
On my computer, the above code creating all the views for `res.config.settings`,
which is an extreme case because the view has 100 inherited views,
allows to reduce the validation procesing time from 9.42s to 8.18s.
I include in the pull request the speedscope profiles screenshots.
Regarding the algorithm for `_get_node_groups` itself:
```py
In [0]: %timeit tuple(tuple(n.get('groups').split(',')) for n in node.xpath('ancestor-or-self::*[@groups]'))
10.1 µs ± 91 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
In [1]: %timeit groups = [tuple(n.get('groups').split(',')) for n in chain([node], node.iterancestors()) if n.get('groups')];groups.reverse();tuple(groups)
3.46 µs ± 29.2 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
```
closesodoo/odoo#107742
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This is a rare case where method _read() raises a MissingError instead
of just ignoring it.
The issue is triggered by several conditions on a model M:
- at least one ir.rule on M with a domain using a column field on M;
- one deleted record Y which is in the prefetch set of a record X;
- one reads a non-column field on record X.
Fix method _read() to manage that case. It adds an extra call to
exists() in that case, but adds no overhead in the general case.
closesodoo/odoo#108050
X-original-commit: 1876dc87e5c88c711c9b3882c39be704ffc46532
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
The - Split Expense - feature was introduced in odoo/odoo#90770
In this commit we fix the following bug, related to it:
Steps to reproduce:
- Create expense with tax_ids.
- Click on - Split expense on the expense form. From the first
hr.expense.split line remove the tax_ids. Rename it as '1',
so that it is easier to find it back for checking later on.
- Click on - Expense split on the wizard.
Check the resulting expenses. Specifically, the one with the name '1'.
Current behavior - The tax_ids field for the first expense
(with the name '1') is still populated.
Expected - The tax_ids field for the first expense should be empty.
On top of that, we introduce the tests that check Split Expense flow.
task - 2831024
closesodoo/odoo#108049
X-original-commit: 3aaf4f1ee2967793c9a4c29766cec63d2c6e3cf4
Related: odoo/enterprise#35005
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When creating an employee with an associated user, the work email of the
employee is copied from the user (or actually the partner associated with the
user).
However since this [commit], both the mobile_phone and work_email fields on the
employee are computed fields based on a linked partner in the work_contact_id
field. This partner is created on the fly if it did not previously exist.
Both of these behaviors interact in such a way, that the linked partner of the
employee is created automatically using the email from the linked partner of
the user. This is a bug, since both linked partners of the employee and the
user should be the same.
The bug is easily resolved by adding the work_contact_id field directly to the
values dict for the creation of the employee (instead of the work_email).
Reproduction steps: the bug can be easily triggered by repeatedly installing
and uninstalling the employees app. An extra partner gets created for each
employee in the master or demo data, after each install/uninstall cycle.
[commit]: https://github.com/odoo/odoo/commit/3c6060b7bbe9c67aca8073ef43c1e89fb7e820ca
opw-3031187
closesodoo/odoo#108045
X-original-commit: 35b7e0e128f1cfd72c11ebb16d68bc48fdcbdb57
Related: odoo/enterprise#35004
Signed-off-by: Kevin Baptiste <kba@odoo.com>
A typical Odoo worker is able to handle ~20 requests per second. With a
default limit to 8192, it means that the worker is recycled after
8192 / 20 = 409s ~ 7 minutes.
There is no reason to recycle a worker that often, since there are
other means of limiting the resources allocated to a worker such as the
memory limit.
We increase the default limit request to 65536, therefore the lifetime
of a worker should be extended to ~1 hour in peak times.
closesodoo/odoo#107970
X-original-commit: a24d32003af334d63f04d6892dbc2e4383a65301
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit replaces the .h2 with the .fs-2 class on the
MobileCompanyMenu checkboxes' icons to keep the same visual size but
without the other styling changes made for the header-like tags/classes.
This avoids an override of the .fa font-family which breaks the Font
Awesome's icon font.
Note: this is a "symptomatic fix" ; the proper fix should be to look for
the override's cause (cf. o-bg-color mixin).
closesodoo/odoo#108051
X-original-commit: 2aa76227296767701b1ea4b2e78e0701a061cf6f
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit sets the username's foreground color to match the one from
the body to avoid having a white text on a white background (cf. bg-view
for the background).
Note: the dark mode isn't affected
X-original-commit: 35072cab808ca0598cd16b7294d07abb42758c78
Part-of: odoo/odoo#108051
Steps to reproduce:
1. Create a new tax (TAX1) with a lower sequence than VAT(15%).
2. Check Affect Base of subsequent taxes.
3. Create an invoice, add a line with a product and both taxes.
4. Remove the invoice line.
5. Check Journal Items tab: a VAT line is still there with an amount
Bug:
When we create an invoice line with (affecting + affected) taxes,
4 Journal items are created, including the affecting tax line
having the affected tax as tax id.
When we remove the invoice line, the system sync the dynamic lines,
recomputing all the taxes to check what to create/write/delete
As one of the tax entries has a tax it will be left as a needed line
while it should be removed.
FIX:
avoid computing `_compute_all_tax` for tax lines
closesodoo/odoo#108048
X-original-commit: 4fbd639965107fc9363dddb553a70461cd596c0c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Before this commit:
There is not any message displayed when the search was performed on icons but
not received any results.
After this commit:
Now there is a no-content message so that users know that the search was
performed.
closesodoo/odoo#108029
Task: 2745855
X-original-commit: e7babea2b5ecaee550635adbaca435091f51a6cb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
Use the top right arrow to navigate from a record that is in the draft stage
to the record that is in stage sent and use the arrow to come back to a record
that is in the stage draft. The theme selector is added to the sidebar.
After this commit:
Now theme selector will not be added to the sidebar.
Task-3016118
closesodoo/odoo#108026
X-original-commit: 44e388bbb2749b342985b11b71d50535bb5a5c1c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, following this flow:
- From the documents app, click on the "share" icon of a document,
- In the website builder, in edit mode, paste the link in the link
tools,
- Save and click on the link,
=> There is a traceback coming from cross-origins errors with the iframe.
These documents should be opened in the top window, as it does not make
sense to open the pdf viewer inside the iframe. This is defined in the
website module, to avoid creating a website_documents module just to
patch the WebsitePreview._isTopWindowURL method.
[1]: 44da4bf
task-2687506
closesodoo/odoo#107860
X-original-commit: 2e8fce06cbe4e2d24dd80eca1c59a9d44d181d30
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit, following this flow on the website builder:
- Add a new .xml page,
- From the page manager, click on the record to open it,
=> There is a traceback as the website service parses the html document
as an editable one.
This commit fixes the test introduced in [1] to hide edit options on non
editable documents. The test is updated to check:
1/ If there is a dataset (the document of an XML file opened on Firefox
will not have a dataset),
2/ If the dataset has a websiteId key. It is the case only for website
pages, rendered using the 'website.layout' template, and not for other
files (js, css, scss, less, xml, csv).
[1]: https://github.com/odoo/odoo/commit/44da4bfcc30ca4fe78a1e0c5cb2f9f498ba6e72e
task-2687506
X-original-commit: bf2c6abdded1509ae22ed299abaa39fa066efb7d
Part-of: odoo/odoo#107860
Previously, it was only possible to upload a bill, so the partner_id was read
from the vendor in the imported file. Now, it is also possible to upload a
file to create an invoice, so we need to be able to decode the customer in
the imported file.
opw-3072989
closesodoo/odoo#106942
X-original-commit: c52cde5405dcc5f3e48fea9b380a93d4a56467b5
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Currently, when a db is loaded without demo data, or that a user has no
task assigned and no personnal stage, the view 'My tasks' is empty. The
purpose of this commit is to assign default personnal stage to a user in
these case to ease the understanding of new user of what the view can be
used for.
This commit :
- add default personnal stage to user the first time he clicks on the
'My tasks' menu if the user has no personnal stage and no task are assigned
to him.
task-3047496
closesodoo/odoo#105940
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, the encoding unit used in the timesheet app was a
`Many2one` field and the user can select the UoM to use. However, only
2 units of measure are supported on the Timesheets app, the `Days` and
the `Hours` records created in the data. Also, when the encoding is in
`Days`, the user cannot directly know he can just set 0, a half-day or
a day for a timesheet in the different views of the Timesheets App.
This commit replaces the many2one field by a Selection one containing
2 choices, one for `Days / Half-Days` and another one
`Hours / Minutes`, to explicitly restrict the choice to the UoMs
supported in the Timesheets app. Also, the label of the both choices
is more detailed to explicitly notice the user will can select a
half-day or day is the encoding unit is `Days / Half-Days` and can
edit the hours and minutes on a timesheet when the encoding method
selected is `Hours / Minutes`.
task-3067111
closesodoo/odoo#105905
Related: odoo/enterprise#34043
Related: odoo/upgrade#4040
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
- Install `HR` module
- Go to Employees
- Open the Employee ('' Ex: Abigail Peterson')
- Archive
- Check `Detailed Reason` in Employee Termination wizard
Issue:
Currently, the detailed reason appears in a small width.
In this commit, we will show the detailed reason in full width.
closesodoo/odoo#108030
X-original-commit: a697bb7234f270298e3f7e6516d635c395aa32d6
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- Set up a recaptcha on a DB
- Drop a form block on a website page
- Click on the submit button
- Toggle the Show ReCaptcha option
=> A traceback is displayed. The bug is quite obvious: we try to render
a XML template which has not been loaded.
A bit of history:
Before [1], the "google_recaptcha" app was a dependency of the
"website_form" and "website_mass_mailing" apps only. Both needed to
render this recaptcha XML inside a snippet option JS file. That XML
definition was lazy loaded by the related JS widget: it made sense for
the XML definition to be defined in the "google_recaptcha" app, as an
util to be lazy loaded.
After [1] and before [2], the "website_form" app was merged in the
"website" app directly. The "google_recaptcha" app thus became a
dependency of the "website" app directly. The same XML was still lazy
loaded by "website" and by "website_mass_mailing". Since the "website"
app is a dependency of the "website_mass_mailing" app, it could have
made sense already to move the XML definition from "google_recaptcha" to
"website". Although as it was still lazy loaded, it still made sense to
keep it as a "google_recaptcha" util.
After [2], however, the XML lazy loading was entirely removed. That
change is debatable (and being debated again for future versions). But
meanwhile, the XML definition still in "google_recaptcha" was put inside
the "web.assets_frontend" bundle. This is wrong at multiple levels:
- Website visitors never need that XML definition, it should never have
been added in there. We'll keep it however to respect stable policy.
- Since [3] (which occurred before [2]), the website editor UI is now in
the backend. Having the recaptcha template XML definition defined in
"web.assets_frontend" makes it inaccessible to editor options.
A fix could be to add the recaptcha XML definition in the
"website.assets_wysiwyg" bundle in the "website" manifest (as both JS
files which need that XML definition are defined in that bundle in
"website" and "website_mass_mailing"). It could be not really robust
though: if another custom app adds "google_recaptcha" as dependency and
put the XML definition in a different assets bundle, there could be
potential problems of having the same XML loaded twice (while the lazy
loading of before was smart enough to not load the same XML file twice).
As a fix, we put the definition in "web.assets_backend" directly. In
master, we may want to consider to reintroduce XML lazy loading and/or
move that XML file in "website" instead of "google_recaptcha".
[1]: https://github.com/odoo/odoo/commit/f8882698e8f4d1a3ad081522778344e2bd7aa0de
[2]: https://github.com/odoo/odoo/commit/39ea7a1fab257ab46a8faf97eea75cc37f8c43e5
[3]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
opw-3076185
opw-3096657
closesodoo/odoo#108005
X-original-commit: e76599d4b52f8c6a797907aeade5060dacd2987a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Steps to reproduce the bug:
- log in as admin
- Go to users, edit Michel Admin
- Add “Manage Multiple stock Locations” permission
- Create a purchase order:
- Add any storable product
- confirm PO
- Receive product
Problem:
The "Deliver To" field is misaligned, and the following fields are off
by 1 column as well. Because the “reminder” field is made invisible when
`effective_date` is not false but its label is still visible, so an
empty place is still present in the view
Solution:
If the “reminder” field is invisible, its label should also be hidden
opw-3097481
closesodoo/odoo#107995
X-original-commit: d02d5f93619445f6f29536442378c9bd1f72454a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Install mrp
- Enable Allocation Report for Manufacturing Orders in settings
- Go to WH/MO/00003 from the demo data in runbot
- Click on the “Allocation” button
Problem:
Traceback is triggered, we try to format the info from the source
("Manufacturing order") and send it in an HTML request, but we access
the `partner_id` field, while this field does not exist in the
"mrp.production" model:
https://github.com/odoo/odoo/blob/f310d8f16b57c776ad92406bd52daa707ad45a88/addons/stock/report/report_stock_reception.py#L373-L374
The first element is always considered as a `stock.picking` but it
can be the `mrp.production`
opw-3063172
opw-3086714
closesodoo/odoo#107942
X-original-commit: 2008cb69dca14d0fe9fbd4484b52912fd4ea68b4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The product matrix was recently converted to OWL but the design was not
adapted to v16 style.
This commit revamps the table to better fits Odoo 16 design.
The previous table had issue with wrong color in dark mode and the
table head title were not aligned with the inputs.
task-3074063
closesodoo/odoo#107102
Related: odoo/enterprise#34743
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
*: base, account, crm, hr, hr_attendance, test_access_rights
The various public methods of the ORM can be override in other models,
those overrides sometime don't implement the exact same signature as the
original method in the ORM. In this work we sanitize all the overrides
to ensure a better compatibility. The background objective is to make it
possible to call any public method using kwarg: `search(domain=[...])`.
* `search`, the first parameter was renamed from `args` to `domain` in
0e9adf7 but the overrides were not updated.
* `invalidate_models` and `invalidate_recordset`, a new `flush=True`
parameter was introduced in 9c3b9a4 but the overrides were not
updated.
* `update`, there is a clash between the `update` method responsible for
writing on a record and `update` in bus responsible to update the user
presence. The bus method has been renamed so it doesn't clash with the
ORM.
This sanitization comes with a new linter that verifies that all
overrides of BaseModel public methods share a compatible signature. The
linter has been disabled for `create`, `write` and `default_get` as too
many overrides don't respect the signature of BaseModel.
closesodoo/odoo#106999
Related: odoo/enterprise#34991
Signed-off-by: Julien Castiaux <juc@odoo.com>
This PR is mainly meant for the support.
Note that the `stack_info` is purposefully accessible to add some stack trace in the logs.
Example of support tickets where it can be useful:
A certain field of a particular model change it's value with no particular pattern and way to reproduce.
With this commit, we can now create an automated actions on the model update trigger to dump the current stack that will lead us on the action that did trigger it.
closesodoo/odoo#75320
Signed-off-by: Julien Castiaux <juc@odoo.com>
- sync both versions of the doc
- spellcheck/unify the wording, capitalization, etc.
- "Odoo" is not a person, and using it in documentation sentences is
generally redundant and weird, unless there is a real ambigiuty.
By default, it's clear that everything we're talking about is
Odoo-related.
Part-of: odoo/odoo#75320
Before this commit, the text of a `CopyClipboardButtonField` could be
edited with a `label` option. But this label was never translated.
After this commit, the field `string` is used instead to rename the
button. This is automatically exported for translatation.
task-3054813
closesodoo/odoo#105560
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Victor Feyens