Steps to reproduce:
- Set warehouse to two-steps reception
- Create a BoM using a MTO (buy) component
- Create a MO for 2 units of that BoM
- Produce 1 and create a backorder
- Open the Overview
Issue:
When there is a backorder (or if the MO is splitted), then when browsing
the dests through `_rollup_move_dests()`, at some point it will branch
into two differents path, related to each backorders. This will raise a
traceback, as we only expected a single MO at that point.
To avoid this, we made the `_rollup_move_dests()` method batchable, so
we can fetch all moves linked to a manufacturing order in a single call,
avoiding this issue.
Note: For consistency sake, updated the `_rollup_move_origs()` method to
be batchable as well, to avoid confusion when using one or the other.
opw-3849252
closesodoo/odoo#161790
X-original-commit: d2830fccbe5dc733673d048303f573bb57a398a6
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Steps to reproduce:
1) Set up mondial relay and publish it
2) Go to /shop, add a product and checkout
3) Choose a pickup location of mondial relay
4) Reload the page
5) Observe an error 'You cannot edit the address of a Point Relais'
Reason: a partner was created without
mandatory field 'phone` for the shipping address
Solution: do not check mandatory fields for mondial relay partners
as it is not allowed to edit them
closesodoo/odoo#162047
Signed-off-by: Valeriya Chuprina (vchu) <vchu@odoo.com>
The payment method's `support_tokenization` field was incorrectly set to
`False` instead to `True`. This didn't prevent the SEPA Direct Debit
provider from tokenizing this payment method because it always creates
tokens when a payment transaction is confirmed. However, the payment
method was not shown in payment contexts where tokenization is required
(e.g., Subscriptions' portal page, /my/payment_method page).
opw-3756773
closesodoo/odoo#161561
Related: odoo/enterprise#60562
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit adds slight improvement to the design of remote work
by adding margin to "Set Location" button.
task-3693392
closesodoo/odoo#157502
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps to reproduce:
-------------------
[A] Create an automated action with:
- Model: Tasks (project.task)
- Trigger: On save
- When updating: ID (to mimic "on_create" trigger)
- Execute code:
```py
record.message_post(body="This is a message from automated action (fields triggers: ['id'])")
```
[B] Create a server action (contextual action) with:
- Type: execute code
- Model: Tasks (project.task)
- code:
```py
record.write({})
```
[C] Test:
- create a new task --> message has been posted (OK)
- write some values on the task --> no message has been posted (OK)
- run the server action --> message has been posted (KO)
Issue:
------
No message should be posted as the ID field has not been modified.
Cause:
------
`if not self._context.get('old_values')` is considered as `True`
because we have an empty dict.
In fact, when we make a write on a record, old_values will be always a dict.
```py
old_values = {
old_vals.pop('id'): old_vals
for old_vals in (records.read(list(vals)) if vals else [])
}
```
Solution:
---------
Old values are not defined in the context during a create.
We can compare `self._context.get('old_values')` with `None`
to differentiate between creating and writing on records.
opw-3736068
closesodoo/odoo#155832
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps to Reproduce :
- Install eCommerce.
- Drag and drop the "Donation" snippet.
- Click on the prices in the snippet.
- Toggle the "Pre-Filled Options" option.
- => There is a traceback.
This bug is due to the fact that since commit [1], all templates have
been added to the OWL app. With OWL, a t-foreach in a template can no
longer loop over a 0 number and causes an error if we try to. This is
what happens here, as toggling off the "Pre-filled Options" option sets
the donationAmounts to 0, which is then used in a loop in the templates.
This commit fixes this by replacing the number by an empty array, so the
loop cannot fail.
[1]: https://github.com/odoo/odoo/commit/4703e4a2efa9213979307e4d3dedeedc61ad0fc3
task-3859207
closesodoo/odoo#161431
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Product domains were not considered when computing the min amount to reach to get a discount. For
example, if you created a discount with a minimum amount of 100 for product "X", the discount
would have been applied, even if the amount for "X" was less than 100, as long as the total amount
of the SO was at least 100.
After this fix, only products that match the domain will be considered when computing the amount
that should be compared to the discount's min amount.
opw-3626345
closesodoo/odoo#155085closesodoo/odoo#162020
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Louis Tinel (loti) <loti@odoo.com>
To reproduce:
- Create 2 lines with the same balance but only one has an analytic_distribution (of 100% on an analytic account).
- Create a transfer of accounts for these
=> The counterpart has a distribution of 100% or no distribution.
Indeed, we simply put the distribution of the last line.
It makes no sense: analytic "balance" is generated and does not reflect the transfer move.
We should make a prorata of the distributions of the lines to transfer.
closesodoo/odoo#161982
X-original-commit: dcfe607d48021902c88b79a571a15559434d1592
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
This commit removes the unnecessary duplicate of the 'o-input' class being present
in the template of the (Multi)RecordSelector components. As the RecordAutocomplete
component uses the Autocomplete component, which already set this classname on its
<input> node, the class was present twice in the DOM.
This could affect the style when trying to write a rule on .o_input since both elements
would get the style.
Now, only the input keep the class, which makes things easier and more predictable.
closesodoo/odoo#161934
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
According to https://www.easytax.co/en/countries/greece
the vat number format for Greece is EL123456783
instead of GR12345670.
We also delete the line for country code `el`
from `_ref_vat` dict as we use `gr` for Greece.
opw-3845662
closesodoo/odoo#161955
X-original-commit: b97c74e43638d685b2af8ede4940f37b6a5cd031
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Issue:
======
The powerbox keep increasing in size when you input.
Steps to reproduce the issue:
=============================
- Install arabic
- Go to notes
- write `/`, you can see the powerbox is a bit smal
- use `down/up`arrows to navigate in the powerbox.
- The powerbox width increase until finally gets to it's intended
position.
Origin of the issue:
====================
Since we are providing that `marginRigh` should be equals to `20` in
`getRangePosition` we will move the powerbox to the left a bit and then
with the style property `max-width=100%` it will increase in size
because the current size is a bit small for it. So at every key pressed
it will increase by 20px until it gets to a point where everything is
set and the `marginRight=20` is finally visible.
Soltuion:
=========
We set min-width as max-content so we can position correctly the
powerbox knowing it's final width.
task-3721794
closesodoo/odoo#161924
X-original-commit: b815447bf239049b37a3705cd014c67e3897ba9c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Steps to reproduce:
- Create a project with a task with a sub-task
- Assign manually the sub-task to the project
- Create a product that creates a project based on this product template
- Create an SO with that product
> A copy of your project template will be created and assigned to the SO
Expected Behavior:
Just as in 16.4, the copy of the subtask created during this process
should be associated with the copy of your project template.
Current Behavior:
The subtask is associated with the original project template.
Cause of the issue/Fix:
Confirming the SO will call the copy method on your project template.
During this call copies of its task and sub-task will be created and
should then be remapped to the correct project/task using by the
`map_tasks` method call:
https://github.com/odoo/odoo/blob/f31174e02157e612650e77ebba3ed1fe54b96776/addons/project/models/project_project.py#L436-L437
This use to do the job correctly in 16.4 because of these lines:
https://github.com/odoo/odoo/blob/ce28edbaae5a9af0a8c6e1f2addf4285ec56e9e1/addons/project/models/project_project.py#L415-L419
However, these were removed by Commit 62e53fa, probably because the new
write method of the "project.project" model introduced by this commit
sometimes relies on the "project_id" of these tasks and this information
should be consistent with the future value of the "project_id" of these
tasks. However, the "project_id" of these tasks should still be remapped
to the copied project at some point and in my opinion this should be
done before the new write method is called, so that this method can be
used correctly.
opw-3823013
closesodoo/odoo#160625
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Rewrite the mapping from xmlid to tax to only take into account
standard taxes from the 'account' module
closesodoo/odoo#161945
X-original-commit: d31f3382453a1d288b732e7cb2aa27b26dcfe645
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit:
* when a user changes 'user_id' to set the same previous 'user_id', the
assign date 'date_open' is updated but it should not as the responsible
did not change;
* when a user changes the salesperson 'user_id' of a crm lead, it triggers
a recompute of 'team_id' that triggers a recompute of 'stage_id' that
updates 'date_last_stage_update' even if the stage does not change, which
happens frequently when changing leads within a given team (new assign,
salesperson on holidays, ...)
* when merging opportunities, 'user_id' can be set on the main opportunity
which triggers a recomputation of both 'date_last_stage_update' and
'date_open' as explained in above points;
Reason:
The 'date_last_stage_update' field depends on 'stage_id' which depends on
'team_id' which depends on 'user_id'. As a result, when 'user_id' changes,
'date_last_stage_update' also updates.
Moreover those fields are implemented using editable stored computed fields
which are triggered everytime a value is given to those fields, even when
the same value is given.
After this commit:
'date_last_stage_update' and 'date_open' will only update when there are
real changes.
Also fix 'date_open' update when lead is converted into an opportunity.
'date_open' is the date when a user is assigned to a lead / opportunity. It
should not be set when converting a lead to an opportunity, as those two
flows are different. Only setting a responsible should update it.
Task-3515225
closesodoo/odoo#161918
Forward-port-of: odoo/odoo#144848
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
date_open should not be set when there is no user_id set. Let us be coherent
so that we can see the effect of assigning users that updates the date_open
field.
Task-3515225
X-original-commit: 3720e5aefd7bf9971d0d7b6fc93fc90c1eeecad3
Part-of: odoo/odoo#161918
'date_open' is the date when a user is assigned to a lead / opportunity. It
should not be set when converting a lead to an opportunity, as those two
flows are different. Only setting a responsible should update it.
Task-3515225
X-original-commit: a3dbe23b83e7aae108ff72737c69c783e059f603
Part-of: odoo/odoo#161918
Before this commit:
* when a user changes 'user_id' to set the same previous 'user_id', the
assign date 'date_open' is updated but it should not as the responsible
did not change;
* when a user changes the salesperson 'user_id' of a crm lead, it triggers
a recompute of 'team_id' that triggers a recompute of 'stage_id' that
updates 'date_last_stage_update' even if the stage does not change, which
happens frequently when changing leads within a given team (new assign,
salesperson on holidays, ...)
* when merging opportunities, 'user_id' can be set on the main opportunity
which triggers a recomputation of both 'date_last_stage_update' and
'date_open' as explained in above points;
Reason:
The 'date_last_stage_update' field depends on 'stage_id' which depends on
'team_id' which depends on 'user_id'. As a result, when 'user_id' changes,
'date_last_stage_update' also updates.
Moreover those fields are implemented using editable stored computed fields
which are triggered everytime a value is given to those fields, even when
the same value is given.
After this commit:
'date_last_stage_update' and 'date_open' will only update when there are
real changes.
Task-3515225
X-original-commit: 8dc18806847e5240dba6f05bdd80d313bf466ebf
Part-of: odoo/odoo#161918
Just to see how it behaves currently, as we are going to fix some unwanted
changes. Notably
* setting user_id to the same value as before should not update the
date_open value;
* setting stage_id to the same value as before should not update the
last stage update value;
* triggers generate chain update of those fields (changing team_id
changes user_id that changes date_open, ...);
Task-3515225
X-original-commit: a1c72fff151524f636fae3f253d33b8228d0add9
Part-of: odoo/odoo#161918
While in practice you would never get this inverse
called with more than one record at a time, it is
still wrong to get the company of self in the loop.
Fixing it to keep good conscience :)
closesodoo/odoo#161979
X-original-commit: 56fe4f71f0cca2ca11624bd267e1dec4de2ac929
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
`base_vat.view_partner_base_vat_form` creates a new div `vat_vies_container` referenced by other views such as `l10n_mx_edi_stock.mx_partner_operator_form`
All these extension views have the same priority and in this case the later is trying to access the div before it is even created.
We fix this issue by changing the priority of the view that creates the div from 16 to 15.
closesodoo/odoo#161902
X-original-commit: 67e7289296ea12e69cb07864a2974cd5d4e46cf2
Signed-off-by: William André (wan) <wan@odoo.com>
This commit adds a new module to allow delaying the sending of sales
order confirmation emails, thus removing a performance bottleneck in the
order confirmation flow.
This is particularly useful for "flash" sales in which a large number of
event tickets are sold in a very short time span. When the emails are
scheduled to be sent right away, the email rendering that is part of the
payment post-processing keeps the worker busy. When the system parameter
`sale.async_emails` is set to `True`, the email rendering is delegated
to a cron, allowing the payment post-processing to execute much faster.
task-3782827
closesodoo/odoo#157612
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit adds the database ID to the IAP calls made to generate text.
It permits to prevent abuses of OpenAI calls.
task-3740440
closesodoo/odoo#154615
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
How to reproduce
- Send an email to catchall@exemple.com, random@exemple.com
(Note : random@exemple.com is an email witch does not exist)
--> Issue the email is not bounced
To justify the change, this was actually the behavior a while ago, prior to odoo-dev@68a457e
The intent of that commit was to consider other possible routes, so this commit
doesn't contradict the change.
Task-3714565
closesodoo/odoo#161782
X-original-commit: df0c05afbf81ce41c9b1b4cfe93476d4ca397749
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps:
- Login as "Mitchel Admin"
- Install hr_skills_survey
- Delete all employee except "Mitchel Admin"
- Open "My profile"
- Open "Resume"
- Add a skill
Actual result:
- Error due to missing employee
- default_employee_id is using the current record id so a user id
- default_employee_id is not the correct ID
- Can lead to record not existing error or access error
Expected result:
- No error
- default_employee_id is the correct employee of the user
- Default employee in dialog is "Mitchel Admin"
opw-3852542
closesodoo/odoo#161636
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps to reproduce:
- Create a vendor bill with landed costs
- Add section and note lines
- Try posting the bill (ERROR)
Bug:
display lines should be skipped
opw-3715660
closesodoo/odoo#161791
X-original-commit: 3174c4a793f24782d835a15d96376e45b5f333e4
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
Create and print an SO for a customer based in Luxembourg
Expected behavior:
According to Bpost and to the Post of Luxembourg, the zip code should be
displayed before the city name in the address format in Luxembourg.
Current behavior:
The zip code is displayed after the city name.
opw-3791142
closesodoo/odoo#161738
X-original-commit: 83b38fab6cc69d0ed2c6abae34f2b4e76ef8a601
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
In IT localization open tax "0% S (Services)"
Issue: invoice repartition line tax tag is "+02", it should be "+03"
opw-3860109
closesodoo/odoo#161696
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
There is 2 issues with it:
- People that want to use multiple picking type or multiple store after
manufacturing locations. It's not possible since the equals is strict
on the warehouse store after manufacturing picking type.
- The procurement group always use the default manufacture picking type
and ignore the picking type on the manufacture rule that will be use.
This commit checks if the location is a child of the post production in
order to create the procurement group. It would be an issue for people
having multiple step in post prod. But it could be fix by using a subset
of the warehouse post production location.
Check if we have a manufacture rule with the same warehouse in the
current route. It's not perfect but it could give a more accurate result than
today.
closesodoo/odoo#161690
X-original-commit: f82a0f2ea8f3c57bae915520f9e4a25b54b81ce4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue
-----
Reconciliation models are not searchable by specific fields (e.g. name).
Steps
-----
- Open Accounting -> Configuration -> Reconciliation Models.
- Try typing something into search.
- No field are suggested to search on.
Cause
-----
No search fields are defined for `account.reconcile.model`, only filters.
opw-3847744
closesodoo/odoo#161648
X-original-commit: 973ad96c7cf4b37fbdeea463bbf676cfee920975
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Steps to reproduce:
- Change the recruitment access rights of Marc Demo to "Interviewer".
- Go to Recruitment > Applications > All Applications.
- Create a new application and add Marc Demo as follower of the chatter.
- Write and send a message on the chatter.
> Marc Demo will not be notified
Expected behavior:
As discussed the PO of the recruitment module (gmf), since users with
"interviewer" access rights have access to the chatter and since the
sensible informations are now shared via the salary offer model instead
of relying on the chatter of the application model, the followers of the
chatter with "interviewer" access rights should be notified if pinged on
a log note or if a general message is sent.
Cause of the issue:
Since sensitive informations used to pass through the chatter, users
with "interviewer" access rights did not have access to it, and were
removed on purpose from the recipients of the notifications:
https://github.com/odoo/odoo/blob/cd6ed7f9fd2e0654cfb0672d7a9536dca21035cf/addons/hr_recruitment/models/hr_applicant.py#L376-L379
to avoid any leak of sensible information.
Note:
This access right did not exist before saas-16.4
opw-3783965
closesodoo/odoo#161198
X-original-commit: 6e8795cf5a7d51c4682941a253fb158e8e7e874e
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
An update made to the tremol device has changed the expected content of
the price field. It now expects up to 15 characters in this position,
with a maximum of 5 decimal places.
At present we can send prices with a decimal position greater than 5,
doing so will result in an error from the fiscal device.
This commit adapts the content that gets serialised in order to ensure
that the decimal provided is no longer than 5 decimal places.
closesodoo/odoo#161804
Task-id: none
X-original-commit: 3373ac3a7945d25fee70d114816ce23a16d6e0ef
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Steps to Reproduce :
- install indian Accounting module
- click on invoice
- go to vendor bills
- create new
Issue:
- while creating new and confirming, it will throw a warning message, as this
warning required only for eInvoice only (while confirming the invoice) not for
vendor Bills.
Cause:
- while generating warning message there is no specific condition like that it
is not for vendors
Solution:
- if we gave condition that this warning message is only for out_invoice then
the issue will be solved.
task-3657558
closesodoo/odoo#161333
X-original-commit: 6480dccfea696e759d0ed4225f4edc033adbfc0e
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
This commit will make a `willDrag` information available to the
draggable_hook_builder context.
This is needed to fix a resize issue in the gantt view.
See correlated enterprise pull request.
closesodoo/odoo#161670
X-original-commit: 53254591c4a6a31483f409aa2fa072ac2ed0b3db
Related: odoo/enterprise#60623
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
- Transfer move line with amount_currency $0, balance 1000đ
- Wizard transfer not generate counterpart lines
closesodoo/odoo#161727
X-original-commit: e5b84edd7a5aefc3f08db23e6ede8a380c2cb6f9
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
The patch function was changed at commit [1]. This introduced a call to
`Object.hasOwn` which is the preferred way to check if an Object has a
property as its own. However, after multiple user reports, it seems like
a significant amount of user and website visitors still use browsers
that do not have Object.hasOwn implemented.
This commit adds a polyfill to add Obejct.hasOwn in case it is not
found.
[1]: https://github.com/odoo/odoo/commit/04fddc19d4aedd8105e0fda5582288c2bb1833fe
Fixes https://github.com/odoo/odoo/issues/142022
opw-3824593
Part-of: odoo/odoo#160758
It's not possible to push in intercompany location because the warehouse
is set base on the initial move. However in intercompany we don't
have a warehouse in the most cases.
Also there is an issue with the cache holding the route on the product
for the current company. So we invalidate it to retrieve all the routes
among the different companies
closesodoo/odoo#161717
X-original-commit: f16e0a2c954f1dce14880d62b6c07518f7317d1b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Usecase to reproduce:
- Company A Stock -> Interco -> Push to Company B stock
- Create a SO from company A with company B as customer
- Create a pull from WH/A to interco
- Create a push interco to WH/B
- Confirm the SO
Current behavior:
Wrong company on stock.move from interco to WH/B due to rule with
company A
Expected behavior:
Pushed to stock B
It happens because the rule_id is not set during the copy of push_apply.
So it just keep the same rule than the move triggering the push (WH/A ->
interco).
X-original-commit: dc58d7913131f1f4dbeb0e3337e61e0b21f6f0d9
Part-of: odoo/odoo#161717
The linked PR: https://github.com/odoo/odoo/pull/155157/files
Added a default props 'productType' for ProductCatalogOrderLines, the value of this prop wasn't loaded by the backend correctly
resulting in a traceback when in debug mode and trying to open the catalog from sale/fsm
and another traceback when trying to open the catalog from the purchase form
This PR loads the type of the product into the dictionnary corretly
closesodoo/odoo#161541
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps:
- Create a Customer Invoice CI
- Register a full payment P
- Create a Bank Transaction BT
- Reconcile BT with P
- Go to the payment's move and click on "Reverse Entry" button
-> First issue: Two buttons ("Reverse" and "Reverse and create invoice")
It should be only one ("Reverse")
- Click on "Reverse" button
-> The invoice is still marked as "paid", it should be "not paid"
The reason is that `is_cancel_needed` variable is not well computed
in `reverse_moves()` as since 4d3ac4cbd8,
there is no `refund_method` on the reversal wizard, which was used
instead of `is_modify` parameter, which is not enough in our case.
opw-3772117
closesodoo/odoo#161534
X-original-commit: 5f3c1957b391e3395dbebac4ccb6592af9e4a7dd
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Steps to reproduce:
- Drop an Text - Image block
- Click on the Image
- Click on the link button next to replace
- Try typing a URL
=> Typing a URL is hard because the widget keeps re-rendering
Reason: Since [1], the jQueryUI urlcomplete widget was changed into an
OWL widget. This added a call to `urlChosen` on input, which leads to
the SnippetsMenu re-rendering the options.
This commit fixes that by remove the call to `urlChosen`. Nothing is
lost since the input is already handling its own changes. Instead,
urlChosen is only called when selecting an element from the dropdown.
[1]: https://github.com/odoo/odoo/commit/86a9171ec7790aa09f2b9a50dcb26deb029e8bedclosesodoo/odoo#161045
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Co-authored-by: =?UTF-8?q?Nguy=E1=BB=85n=20=C4=90=E1=BA=A1i=20D=C6=B0=C6=A1ng?= <daiduongnguyen2709@gmail.com>
In `SET_FILTER_MATCHING_CONDITION` we would call `SEE_RECORDS_PIVOT_VISIBLE`
twice but since the function returns a boolean value, the second call
was useless as we already knew the outcome. This revision alleviates a
bit the cost of computing the cells' clickable actions.
On A sheet with 480 visible cells, each of them matching the full
condition, the time spent in `getClickableCells` goes from 19ms to 14
ms on Google Chrome and from 42ms to 29 ms on Firefox.
closesodoo/odoo#161656
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Issue: When a course is set to 'On Payment' and
linked to our 'Course Access' product, users
encounter an issue where they cannot view the
final screen of the payment process when selecting
payment methods like 'wire transfer'. This occurs
because the payment status remains 'pending', and
the user has not yet been granted access to the
course, meaning no invitation link is available.
Steps to Reproduce:
1. Install website_sale_slides.
2. Create or modify a course with the 'On Payment'
status.
3. Link it to a 'Course Access' product.
4. Navigate to the website and attempt to purchase
the course.
5. Proceed through all the steps of the payment
process.
Solution: The template needs to accommodate
scenarios where certain payment methods do not
immediately provide an invitation link.
Even without the invitation link, it should still
display the last payment screen, awaiting payment
confirmation to grant access.
opw-3683024
closesodoo/odoo#161618
X-original-commit: eee6222763b4d88f75994b498d15cd4358899fc1
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
clesgow