Before this commit: whenever we left the PaymentScreen when we were paying (either by reloading the page or by backing to the ProductScreen), the real payment status was not properly saved even tho the payment has been paid or cancelled.
With this commit: whenever we go to the PaymentScreen with a pending payment line with Adyen, we fetch the latest status from the back end. This way, the front end will always have the latest status of the payment.
opw-2802676
closesodoo/odoo#90083
X-original-commit: 07b30c519b101a2998f5320dde5203bfc964b7e9
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Purpose is to ensure tools are called like intended, notably by filtering
input and raising if an unexpected value check is asked. Some code is also
made a bit more generic to have the same kind of parameters when searching
for mail.mail.
In this commit we therefore fix some bad calls to assertSentEmails which
were not checking the right stuff.
closesodoo/odoo#90082
X-original-commit: d9759b2ee86b79b4fb2739a4aebd24a8044cf947
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This PR helps redducing the noise in the one introducing the new environment
in discuss. Indeed, the createWebClient helper will always be used so we won't
be able to use the form utils anymore. Moreover, since the clean up of the widget
is now handled by the start method, the calls to widget.destroy in those test was
not required.
task-2582313
closesodoo/odoo#90079
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, the public user would be prevented from creating,
reading, or using payment tokens entirely. This was put in place in an
effort to homogenize the way each application interacts with tokens,
and because it was considered more logical to only create tokens when
you can see actually them afterward. This however led to an undesirable
side effect in Subscriptions where customers would pay while being
logged out, thus preventing the token from being saved and failing the
automatic renewal of the subscription.
With this commit, we enable the public user to create tokens from any
payment flow. This also means that when a token is created, its owner
will not see it until they log in. This commit also reverts 2a084c48
which was intended to hide payments acquirers from the public user if
their payment would end up being tokenized.
opw-2789340
closesodoo/odoo#90061
X-original-commit: 4e03d4b6106f10522dd5f1839a0f941ca6b202fa
Related: odoo/enterprise#26741
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit introduces models that define records being 1:1 map with components,
as a step to move further to having essentially all business code in models.
Having code in models is desirable to have very maintainable code, thanks to
robust and declarative code with an ORM-like architecture.
Task-2831082
closesodoo/odoo#90057
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
For some unknown reason (part of a huge refactoring during the BS3 to
BS4 migration at [1]), a background color was applied to the <header>
(behind the navbar) once it becomes fixed (after scroll if the related
header scroll effect has been chosen).
That $light color made no sense as is visible if the header uses rounded
corners but is impossible to edit / remove.
This commit, for master, simply removes it. This is not possible to
migrate (for example to try and handle the case where the menu color is
transparent) as it would require to know the color of $light. It would
be overkill anyway, this just relies on users with that problematic
transparent header (probably nearly no one) to review their header in
the next Odoo version.
[1]: https://github.com/odoo/odoo/commit/09f40036b9c14161db90c6128861369c91c8c64e
opw-2686695
closesodoo/odoo#90058
X-original-commit: f721e6187933cde4366a7f987fb80612da581670
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This PR prepares the ground for the introduction of the wowlEnv in the discuss app.
Indeed, the local_storage service is not available as a service anymore so the one
from the browser is used instead. In order to reduce the noise in the main PR, this
change is done separately.
task-2582313
closesodoo/odoo#89851
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Current behavior:
The invoice payment term of the report is a p tag with another p tag inside like:
<p name="payment_term">
<span>
<p> This is a payment term note</p>
</span>
</p>
but because nested p tags are not supported in html de result in the browser is something like:
<p name="payment_term">
<span></span>
</p>
<p> This is a payment term note</p>
<p></p>
Similar behavior can be observe for the fiscal position note.
Expected behavior:
The code should respect html format rules and not have nested p tags.
Solution: We replace the parent p tags by div tags, and we modify xml file that have xpath relying
on this tag.
opw-2804933
closesodoo/odoo#88660
Related: odoo/enterprise#26372
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before when reporting in the sale module in a multi-company
environment currencies where not converted to a unique currency
before mathematical operations (sum, avg, ...).
Now before mathematical operations currencies are converted to
the currency of the company currently selected.
Task - 2696759
closesodoo/odoo#83550
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Current behavior:
When 2 steps delivery and product packing is activated, and have 2 kit products that have common components.
If you create a sale order with those 2 kits and pack them in the first step of the delivery. And in the second delivery step mark the pack as done the done quantity in the package
are not correct.
Before this fix, all the products quantities from different kits were on the same stock move line and the other lines were ignored,
this result in lines with too much products and lines with no product. When validating this
incorrect transfer an unnecessary backorder was created and the sale order lines were not correctly marked as delivered.
Steps to reproduce:
- Activate 2 steps delivery and product packing.
- Create Kit A with Component A and Component B
- Create Kit B with Component A and Component B
- Create a SO with 1 Kit A and 1 Kit B
- Confirm the SO
- Go in the first step of the delivery and put everything in a pack
- Go in the second step of the delivery and set the pack as done
- Go in the package details : The first component A has 1 reserved and 2 done, same for component B
opw-2754106
closesodoo/odoo#90033
X-original-commit: b81f70babc774eff2e04d2f7854d75ec7273a757
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Step to reproduce:
- Create an expense for an expense product which has a cost
Current behaviour:
- Expense's unit price is modifiable which shouldn't be
the case according to the help message of hr.expense.unit_amount
Behaviour after PR:
- Expense unit price is only modifiable is there is no unit_amount
(unit_amount = 0)
opw-2781040
closesodoo/odoo#90014
X-original-commit: 44b6d60de301651e52df4c41e32e38d23b0a154e
Signed-off-by: Kevin Baptiste <kba@odoo.com>
It was impossible to create a new gift card or pay with a gift card from the front end.
With this fix, it's possible to use a gift card code in the front end and to generate a new gift card. The gift card product is now available in the pos.
closesodoo/odoo#89999
X-original-commit: 2a9b6a763b11084735cf46ac9aa83b39098b958c
Signed-off-by: Masereel Pierre <pim@odoo.com>
Since those tests are related to the legacy mockServer, they have been
moved to the legacy folder.
task-2582313
closesodoo/odoo#89883
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This PR prepares the ground for the one introducing the new env in discuss.
The signature of the notify function has changed a lot from the one in the old env.
In order to ease the transition and reduce the noise, the discuss models now
rely on the messaging's notify function.
task-2582313
closesodoo/odoo#89877
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: calendar, hr, im_livechat, mail, mail_bot, snailmail, website_slides.
This PR prepares the ground for the one introducing the new env in discuss.
The signature of the rpc function has changed a lot from the one in the old env.
In order to ease the transition and reduce the noise, the discuss models now
rely on the messaging's rpc function.
task-2582313
closesodoo/odoo#89858
Related: odoo/enterprise#26676
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose:
At the moment, you can only find multi applications for the same applicant
based on the similar email.
Not every application comes through the same email.
We want to find same applicants based on the same email, phone or
mobile phone.
task - 2701472
closesodoo/odoo#86428
Signed-off-by: Kevin Baptiste <kba@odoo.com>
PURPOSE
Generic improvements for services.
SPECIFICATION
- For all reporting menus: removed the group by in the search view, and kept grouping
the grid, pivot and graph views by the corresponding field.
- For timesheet/attendance, switched the pivot and graph views from their places.
- Renamed 'billable type' into 'billing type'.
task-2766164
closesodoo/odoo#85726
Related: odoo/enterprise#24940
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Some reports are specific to invoices and are raising an UserError if called without the correct business objects.
Since version 13.0, invoices have been merged into `account.move`.
The test is making a `search` on `account.move` to test the report generation but there is no guarantee there are invoices.
To prevent random failures in the futur, this commit allows custom domain to get the records in order to test these reports correctly.
closesodoo/odoo#85150
Task: 2726507
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
For the Switzerland localization, we need to append some extra pages during the PDF generation such as QR barcodes or ISR payment slip.
There were multiple difficulties with the current codes:
- The ir.attachment was generated before the hook allowing to append the extra pages.
- There is no existing hook allowing to get the pages for each invoice when printing on multiple records at once.
This commit aims to dispatch the generation of PDFs from the creating of extra attachments:
- `_render_qweb_pdf_prepare_streams` is called first and creates a stream for each record containing the PDF pages.
- Then, the ir.attachment are generated if necessary.
- Finally, all streams are aggregated together to get the final PDF.
Task: 2726507
Part-of: odoo/odoo#85150
Globally ease event registrations followup by improving the related search
views and by allowing a quick access to statistics.
Specifications:
1. A stat button has been added on event that go to attendee reporting filtered
on the event
2. a) in the attendee reporting, the text search has been modified as follows:
- order: first search on event
- order + added: then search on responsible
- order + added: then search on organizer
- order: then search on participant
- then other field already present
2. b) still in the attendee reporting, filter "archived" has been moved as the
last filter
2. c) still in the attendee reporting, group by for campaign, medium and source
have been added
3. link to confirmed and expected attendee in the kanban view box now redirect
to the new stat view with the suitable filter
Technical remarks:
- view for a specific event launched from the event view uses a specific
search view which doesn't include search on event (name, organizer, ...).
Task 2761011
closesodoo/odoo#84546
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Globally ease event registrations followup by improving the related search
views and by allowing a quick access to statistics.
Specifications:
1) A stat button has been added on event that go to attendee reporting filtered
on the event
2.a) in the attendee reporting, the text search has been modified as follows:
- order: first search on event
- order + added: then search on responsible
- order + added: then search on organizer
- order: then search on participant
- then other field already present
2.b) still in the attendee reporting, filter "archived" has been moved as the
last filter
2.c) still in the attendee reporting, group by for campaign, medium and source
have been added
3) link to confirmed and expected attendee in the kanban view box now redirect
to the new stat view with the suitable filter
Technical remarks:
- view for a specific event launched from the event view uses a specific
search view which doesn't include search on event (name, organizer, ...).
Task 2761011
Part-of: odoo/odoo#84546
The split allows to:
- have one file per model and shorter files
- ease finding of views
- ease tracking of changes
Task-2761011
Part-of: odoo/odoo#84546
# Main quest
Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
# Secondary quests
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
# Future quests
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
### Credits
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
closesodoo/odoo#87522
Related: odoo/enterprise#25736
Related: odoo/upgrade#3478
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit, py_js was unabled to evaluate expressions
containing "true" or "false" (boolean values, JS syntax), which
seems reasonnable for a python interpreter. However in Odoo, we
often use that syntax in modifiers (e.g. required="true"). For
that reason, we need to add those two keywords in the evaluation
context.
Part-of: odoo/odoo#87522
Before this commit, the makeView test helper processed the given
arch and generated the fields to pass to the View component. This
led us to do a similar work as what is done in the view service,
i.e. duplicate code, or factorize/reuse code.
An alternative is to let the View component fetch whatever it needs
(view arch, fields, search view...). This is the purpose of this
commit. That way, the code of the view service is executed (and
thus tested as well) in each test doing a "makeView".
This commit makes that change, and adapts some tests accordingly
(mainly, tests doing assertions in mockRPC, since we do a get_view
in every test).
Part-of: odoo/odoo#87522
Before this commit, in form views, a call to "getViews" was done
for each field in the div with className "oe_chatter" (i.e.
"message_ids", "message_follower_ids" and "activity_ids"). Those
calls were unnecessary since those fields are displayed with a
custom widget (the Chatter) anyway.
Part-of: odoo/odoo#87522
Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
Part-of: odoo/odoo#87522
PURPOSE
When opening the event page on the website, there is a service worker in place
that pre-fetches all links in order to be able to work offline.
This commit aims to disable the page tracking for those prefetch requests to
avoid polluting the statistics with "fake" page views.
SPECS
- Add a preparation commit to introduce a "X-Disable-Tracking" header
- Put the header on all requests in the event module that prefetch content
See underlying commit for details.
Task-2476513
closesodoo/odoo#86031
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In 2 ways:
- by ignoring prefetched pages: indeed some page were reported inaccurately
as being viewed by the user when they were only prefetched.
- by adding the page /event in the tracked page as the page is obviously
important in the event business
Technical notes:
- The prefetched pages are ignored thanks to an header X-Disable-Tracking added
on each prefetch request in the service worker.
- Adding the page /event as a tracked page has increased the number of queries
when browsing the page /event. That's why some query count have been updated in
TestOnlineEventPerformance.
Task-2476513
Part-of: odoo/odoo#86031
In this commit we add a request header X-Disable-Tracking that enables the
client to ask the server not to track a request.
This is useful for example when the client prefetches pages to be able to work
offline. In that case, the prefetched pages must not be considered as viewed
by the user. In such scenario and without such header, it is not possible to
get an accurate page tracking.
Task-2476513
Part-of: odoo/odoo#86031
Cancelling a picking with scrapped and done SM will cancel this SM too.
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a storable product P
3. Update the quantity of P: 10 in WH/Stock
4. Create a planned delivery order DO with 2 x P
5. Mark DO as todo, Check availability
6. Scrap 2 x P
7. Cancel DO
8. Open the SM of the scrapping
Error: The SM is cancelled. This is incorrect: the move was done, so
there is a quant with 2 x P in scrap location. There is now an
incoherence between quants and SMs report.
OPW-2805604
closesodoo/odoo#89987
X-original-commit: bd3324acc3ec227438d2cb25a1df1e0fca2a2789
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Bug
===
When we called assertMailNotifications in batch, with different
notification status, it might raise an error when it shouldn't.
The reason for that is we check that no mail at all are created, for
the entire batch instead of filtering on the related partner.
`assertNoMail` should only check if no mail are created for the partner
it receive in arguments.
Task-2782150
closesodoo/odoo#89965
X-original-commit: 91be8b1eb2c3592029987524942ae2864988a7d3
Related: odoo/enterprise#26718
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently all iterations share the same dictionary. We have to copy the
default dict in order to have a distinct copy for each id in the loop.
Task-2826303
closesodoo/odoo#89934
X-original-commit: ae145e0909d5f37964eace75053eadf9e8b80c36
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Stopping a threaded odoo server would spam the postgresql logs with
multiple:
<...> LOG: could not receive data from client: Connection reset by peer
Let's avoid being rude and not hang up on postgresql connections
unexpectedly.
closesodoo/odoo#89955
X-original-commit: d0da17b167edee82381b6add573742e1cf663a9c
Signed-off-by: Raphael Collet <rco@odoo.com>
When submitting an Application Form, the name / email / phone number are
not auto-populated.
Step to reproduce:
1. Install "Online Jobs" module
2. Go to /jobs on your website and apply to a job
The form should be auto-populated with the field mentionned before, it isn't.
Solution: From a previous commit [1], the fill-with behavior will replace
the default_values. However, the change was not completed. The
data-fill-with attribute was missing into the XML template.
[1]: https://github.com/odoo/enterprise/commit/fe5a2ffe30b6f5b5d1bd2e64a0e7f11267b34a96
opw-2803166
closesodoo/odoo#89941
X-original-commit: 5739569b2c2a76e3c091c23a12623e8921794834
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Because private fields would automatically add a bunch of fields to
the user's request (in order to do their own post-treatment), unlike
normal behavior `read([])` would be completed to `read(['privacy',
'user_id'])` and would fail to trigger the "select all the fields"
behavior of `BaseModel.read`.
Move the privacy management to a `_read` override instead. Also update
the code to be more linear and straightforward, without a bunch of
intermediate helper function.
This is also a small performance optimisation, although apparently
much more minor for 14 (best case of about 5%) than on 15.0 (where it
seemed to reach 30). The gain is mostly for private events being read
for non-participants: because the non-public fields get neutered
before computation (rather than after), fields are computed on a
neutered basis and thus largely do nothing. This is especially salient
with computations relying on relations (in this case
`attendee_status`), as from an empty starting point they essentially
do not do anything.
This leads to the effort (and cost) of private events being read by
non-participants to be about the same as the cost of public events,
whereas before the change there is a visible overhead. The signal is
quite noisy though.
NOTE: backported the addition of `privacy` to the public fields from
2f4a91c0ce as that is better
behavior and makes the tests more logical (and easier to forward
port probably)
OPW-2831113
closesodoo/odoo#89936
X-original-commit: b0c6f2969596fb715e0a6c62865b5c7dbc0bcc78
Related: odoo/enterprise#26699
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Previously, updating a component that was mounted out of the DOM would
rerender it and patch it. In owl 1, patched was not called when a
component was mounted outside of the document. This caused crashes when
something done in onPatched depended on something done in onMounted (as
mounted is also not called when not it the DOM, which was handled
correctly by the compatibility layer).
This commit fixes that by ignoring requests to render a component that
is not yet in the DOM as a new render will be initiated anyway when
mounting the component in the document for real.
closesodoo/odoo#89935
X-original-commit: fc6a843abe52cfee084ed476f00a12a8ba1d1669
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, when pasting multiples lines a new step per line.
So when performing an undo, only one line was removed instead of the
whole pasted text.
task-2833740
closesodoo/odoo#89932
X-original-commit: 06fb4e3e8377dedb02644779f0077e0d883df918
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when unsing the function `insert()` with data being
an empty string, the function crashed but shouldn't.
task-2833740
X-original-commit: d44302550ddc027d4891ad04bf16c364e171e5ad
Part-of: odoo/odoo#89932
These helpers are used to create the repartition lines and the taxes in
the upgrade script which upgrades the tags on the taxes.
See https://github.com/odoo/upgrade/pull/3137closesodoo/odoo#89912
X-original-commit: 8927003d0c32e81d28ece68e61c1a737bd7532d2
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Jacky (trj)