Current behavior:
When you have a loyalty program with a free product, and a rule with a
minimum amout. The free product is not added to the order if the free
product is already in the order.
Steps to reproduce:
-Set a loyalty program with the following Conditions:
Minimum Qty: 1
Minimum Spend: $5
Grant: 10 Points/Order
-Reward:
Type: Free Product
Item: Any item (eg: Bacon Burger)
Exchange: 30 Points
1. Open POS that has this loyalty program.
2. Process sales with a Test User until user has 30 points.
3. Attempt to redeem the Free Product under "Reward".
Note: I modified the other test, IMO it makes sense that when triggering
the rewards it adds Product A and Product A * -1. Because if the product
that was already in the order become free, the rule to trigger the
rewards is not met anymore.
opw-3135794
closesodoo/odoo#113313
X-original-commit: 253d308a26f1e6479c1d3c5342e1cede6f635198
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
To reproduce (V16):
1. Force modify a view with an unexisting field
For example `res.users.tree` with:
`<field name="unexisting_field"/>`
( note that odoo won't allow to do so,
you will have to do it in raw PSQL * )
2. Open Settings > User & Companies > Users
=> JS traceback error:
```js
UncaughtPromiseError > TypeError
Uncaught Promise > Cannot read properties of undefined (reading 'string')
TypeError: Cannot read properties of undefined (reading 'string')
at http://localhost:8069/web/assets/debug/web.assets_backend.js:67523:84 (/web/static/src/legacy/legacy_load_views.js:67)
...
```
* : In practice, it happens to Odoo customers after
incorrect installations/removal of apps
After this commit:
The JS traceback is much clearer regarding the error:
```js
UncaughtPromiseError
Uncaught Promise > Missing field string information for the field 'unexisting_field' from the 'res.users' model
```
OPW-3071843
closesodoo/odoo#113345
X-original-commit: 33f82a60cd3bb64e67d939795b774cd332ab0508
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
We use the employee's manager's user's idto fetch a partner by id.
This can cause the action to fail in specific cases as well as
potentially using the wrong language for the reminder
closesodoo/odoo#113282
X-original-commit: c26db495c929d60de62a36cf920c88f6f4c855b9
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, no check was made on conditional questions to see if their
condition was valid when taking a survey.
With this commit, if the survey is not in "random mode" (in which case,
conditions do not apply), there is a check to see that a conditional question
has a valid condition. If not, it is not used in the survey.
Task-3083488
closesodoo/odoo#113303
X-original-commit: f14d1f89ee9c78d481ce1f30ef74bdad9ef0cd7e
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
# Steps to reproduce
* install account_accountant, documents and l10n_it_edi
* Switch to an Italian company
* go to Documents > Configuration > Workspaces and create a new
workspace `W` and it's child `W1`
* under Documents > Settings, activate Accounting and set `Workspace`to
`W`
* save and go back to Documents > Settings, and click `Journals` under
'Accounting'
* add a line with Journals = 'Vendor Bills' and Workspace = `W1`
* go to Accounting > Vendor > Bills and upload a Fattura PA XML bill
* now open the newly generated bill
You should see that the chatter does not load.
# Cause
When uploading a Fattura PA XML bill, a PDF attachment is created and
added to the chatter. The issue is happening because the
`ir.attachment` record ends up in an invalid state where its 'res_model'
field is false.
The 'res_model' field is actually defined when the attachment is
initially created. However, that value ends up being overwritten when a
related `documents.document` is created here: https://github.com/odoo/enterprise/blob/3f53e50989fbb9551565429aede7c0a1e4d6e5a4/documents_account/models/account_move.py#L88
Because of the following line, that `documents.document` will be
assigned a default `res_id` (but no `res_model`).
https://github.com/odoo/odoo/blob/26b2cbd4e5c73ea66456a91ea9cb36d6b174cae7/addons/l10n_it_edi/models/account_edi_format.py#L767
However, setting `res_id` (or `res_model`) on a `documents.document`
will also overwrite the related attachments' values (in this case, the
attachment's `res_model` is set to false because the document's
`res_model` is false).
This behavior happens because of this inverse compute: https://github.com/odoo/enterprise/blob/b4201e6b422e5b0bde1f04db37bcda4941d0665f/documents/models/document.py#L97-L104
opw-3119669
closesodoo/odoo#113299
X-original-commit: 6839abc79a947e30750ec535058828c190c18955
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
When the product configurator is opened, the focus is always on the
custom value input, which may scroll down the configurator and make the
user miss attributes
Steps to reproduce:
1. Install Sales
2. Go to Settings > Sales > Product Catalog and enable Product
Configurator and save
3. Go to Sales > Products > Products and open product 'Cabinet with
Doors'
4. Go to the 'Attributes & Variants' tab and create and edit an
attribute 'Custom'
5. Add a value 'Notes' and check 'Is custom value' and save
6. Add the value to the product and save
7. Open product 'Customizable Desk', in the 'Sales' tab, add 'Cabinet
with Doors' to the Optional Products and save
8. Create a new quotation and add product 'Customizable Desk'
9. The product configurator opens up with the focus on the 'Custom'
attribute input, if the window has a small height, it scrolls down to
that input
Solution:
Remove the focus on the custom value input
Problem:
The focus was made on the input of custom values
opw-3057390
closesodoo/odoo#113301
X-original-commit: dd3e5be00cc4e3408d90abb3923b6658fb1d3073
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Currently, the vat label value comes from the company's country instead of
the customer's country.
So in this commit, if customer country and current company country is same then
we set the customer's country vat label in an error message else we set default `VAT`.
closesodoo/odoo#113295
X-original-commit: 27bae2a04fd333dc54429973d396f329d3710a3d
Signed-off-by: Josse Colpaert <jco@odoo.com>
This commit fixes the shared-worker feature detection with using the
browser object alias.
Steps to reproduce:
- Log to Odoo back-end with a device without a shared-worker support
like Chrome on an Android device => traceback
link:
https://caniuse.com/mdn-api_sharedworker
opw-3198778
closesodoo/odoo#113293
X-original-commit: 4aaafd46dbe1188bf2d9c0140a916ef664d99c42
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This PR fix a traceback that occur when pressing spacebar while the confirm
dialog for deleting a link preview is open.
task-3196494
closesodoo/odoo#113274
X-original-commit: d46a5171378497992bd65634f1aded53db27e9ef
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
1. Install [Expenses], [Indian - Accounting], [Accounting] on Apps
2. [Settings] [Users & Companies] [Companies]
- create a company based in India with address there
3. Enter [Expenses], [CREATE]
- create and add an employee w contact info (private address) in India
- set paid by: Company, write an amount, category > [CREATE REPORT]
- [SUBMIT TO MANAGER] [APPROVE] [POST TO JOURNAL ENTRIES]
4. Click on the [Journal Entry] created at the top right corner
Issue: Missing pos field hinders revising it by [reset to draft]
Resolve by: change the requirement in view and enable further revision
Impacted versions: 16.0 up to master
opw-3168426
closesodoo/odoo#113270
X-original-commit: bc08a6e9d0cc42d1586913bf95d01d4547c13b05
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Clicking on draw in the signature dialog should clear whatever is already drawn
on the canvas.
task-3040855
closesodoo/odoo#113248
X-original-commit: f1c3d83f5b4f6ef0e2b5db2b7aa55344c91454f0
Related: odoo/enterprise#37338
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
This method is not used by rpc calls and wrongly allowed users to read the standard_price
field by calling the method through rpc.
Make it private to reduce its uses and avoid this potential leak of information.
closesodoo/odoo#113234
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Clarify the uses and impacts of current_attributes_price_extra and
no_variant_attributes_price_extra context keys.
Group the key specification and usage.
Provide a clear API shared by templates and variants.
Part-of: odoo/odoo#113234
Since 4d2b04a843, invoices
auto-generated on Sales Order payment were not sent to
customers.
Invoices are only marked as 'posted' in the override
of `_reconcile_after_done` in account_payment which means
`_send_invoice` must be called after the super call s.t.
the invoices are correctly posted before being sent.
opw-3158620
closesodoo/odoo#113229
X-original-commit: 82c53dd3404992b14d1db331c37b6d03c9f0ace1
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The X report of a PoS is a resume of the sales/refunds and other information of the session.
It can be printed at any moment of the session.
The Z report is the same as the X report with a bit more information like the starting and
the ending datetime of the session. It can only be printed after the end of a session.
The Z report can only be printed with the Swedish and Belgian localization at the moment
and the goal is to make it available in the standard version. This commit also adds some information to the
reports like the different invoices done during the session and also changes the layout of the reports
to be more readable.
closesodoo/odoo#113228
X-original-commit: b8b9067642fd75c2c02b202d9cffac98a4e150d4
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Since [this commit], it is possible to have a block only displayed on
mobile screens. This feature can break the steps snippet by following
these steps:
- Drop a steps snippet in a page
- Set the third step to be visible only on mobile
=> The connectors are broken.
This commit fixes this issue by only considering steps that are visible
in desktop view for connectors drawing.
[this commit]: https://github.com/odoo/odoo/commit/3103e0553011b5c1f4078972d7a88fa3fd4068b2
task-3116227
Related to opw-3135927
closesodoo/odoo#113184
X-original-commit: d8521d197518e90d63443d1095b2df84487ad4ae
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
From [this commit], it is possible to define the visibility of blocks
according to the device on which the page is displayed (either hide on
mobile, or hide on desktop). This change has brought two problems on the
table of content block:
1. The sub-component s_table_of_content_main (the right part) can be
invisible, which does not make sense.
2. The sub-component of s_table_of_content_main can be invisible but it
did not change the navbar of the TOC.
This commit prevents hiding the main part of the TOC and rebuilds the
navbar of the TOC according to the device visibility of its
sub-components.
[this commit]: https://github.com/odoo/odoo/commit/3103e0553011b5c1f4078972d7a88fa3fd4068b2
task-3116227
Related to opw-3135927
X-original-commit: b7f9c26a93e58f2ace964ab6b05132cc9f8f3366
Part-of: odoo/odoo#113184
By following these steps:
- Drop a block table of content on a page
- Disable the visibility of the block in desktop view
=> A traceback is displayed.
This is because for scrollspy to work properly, the elements that it
handles must be visible (no display: none). Unfortunately, we put a
display none when the block must be invisible for a certain device and
the width of the screen is the one of this device. Since it is quite
complex to prevent all the cases where the block could become invisible,
we patch the scrollspy component of bootstrap so that it has a similar
behavior as in version 4.X. (not cause an error if the navigation
element is no longer in the DOM or is no longer visible).
The error is only visible since [the migration from bootstrap 4 to
bootstrap 5] because to add the class, bootstrap 4 did it with the
JQuery addClass() function which does not cause an error if the element
on which it is called does not exist. Now, bootstrap 5 does the same
thing in pure JS with classList.add() on elements that meet the
requirements (visible) which causes an error if the element on which it
is called is not defined (this is the case before this commit because
the TOC was not visible).
[the migration from bootstrap 4 to bootstrap 5]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
task-3116227
opw-3135927
X-original-commit: f2b86dda77133ed9c4f02394693e771758d18bad
Part-of: odoo/odoo#113184
A/B testing was used in the past to create mutually-exclusive mailings.
Since then a 100% limit for the recipients of an A/B campaign.
As there is no technical reason for this limit and not having it allows
for a special usecase, it is replaced here with a text warning.
The usecase in question being that as the domain of the different
mailings composing a campaign may be different, users may want to
take advantage of the fact that only 1 email will be sent to each
address to avoid sending 2 mailings when only one or the other should
be sent. Consequently users may want to use 100% of the domain on
every mailing in their campaign.
As the ab_testing_total_pc is only used for that purpose the field
is removed. 'total' field is not always accurate and is unused so
it is also cleaned up.
task-3008627
closesodoo/odoo#105639
Related: odoo/upgrade#4257
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit: if a different `web.base.url` is set with
`web.base.url.freeze`, during the first synchronization of Google
calendar it will show a mismatch URL error. The problem is that we
send the `redirect_uri` based on the `web.base.url` in the
`_get_authorize_uri` function.
The solution is to use the request root URL instead.
opw-3101741
closesodoo/odoo#113215
X-original-commit: 6d713e69e6f412c05fe2af81fb263e09713b4821
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Before this commit, the online plane icon when the user is
on leave had the same color as background. As a result, the
plane icon was not visible.
This commit fixes the issue by adding the missing `text-primary`
classname, which adds the green color to state "online".
Task-3196190
closesodoo/odoo#113195
X-original-commit: 2268d625a29ab2d4b9b40bab4520e6204b7763a0
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Install a database with many langs, arab, french, english, ... Keep
english as the default lang. Start a shell and validate a sale-order
using the superuser. On the web client, the sale order has been
validated in arab instead of in english.
In 16.0 the `context_get` method was changed to ensure there was always
a lang set in the returned context. It used the following fallback
order: context > request. The solution was partial because in case there
was no request to extract a lang from, no lang was set on the context.
In a recent 16.0 fix (f2523c4a), the mechanism was changed to fix the
previous problem. The fallback order became: context > request > first
installed lang. This solution is sub-optimal because the first installed
lang isn't always the best pick. e.g. when you have a mostly english
company but that arab is installed for some website pages, arab is
selected instead of english (the langs are alphabetically sorted)
In this work, the fallback order is changed once again:
1. The lang set on the user's profile if activated
2. The best lang extracted from the user's browser if activated
3. (new) The lang of the user's current company if activated
4. (new) English if activated
5. The first lang (ordered by ISO code) if any
6. English
The 3rd should cover most of ill-cases. For the 4th step, we assume that
english is prioritaty to other installed langs when no lang standout.
closesodoo/odoo#113186
X-original-commit: 03134bf7cb1e3d63f3be435fbc734e6198ca029b
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Community PR: https://github.com/odoo/odoo/pull/112978
Since the transition of the inventory adjustments view to owl in https://github.com/odoo/odoo/commit/350a7a0d6f4816ee75676b80a9a5b9769bf80fe6, a bug was introduced in the inventory adjustments view.
To reproduce:
- Go to inventory adjustments page
- Enter a 0 quantity in any of the Counted Quantity lines.
- Press enter/tab/shift-tab to confirm.
When focussing out of the field using the mouse after editing the field value, the difference field gets updated automatically, however when using a keypress as above, the field just stays the same.
Solved by adding overridden `onKeydown` behaviour in the `counted_quantity_widget` similar to the existing `onInput` behaviour.
closesodoo/odoo#113040
X-original-commit: 3cf3d2ba17265cc8f17facaf8a6bece0b6eddcbe
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit:
1. Set up an EasyPost shipment setup, using
"Canada Post" as the Carrier Type and
"XpresspostUSA" as the Default Service Level.
2. Create a SO with a US customer (like Deco Addict)
3. "Add Shipping" using the button and choose the one created in 1.
4. When you try to "Get Rate" using the EasyPost shipment,
the API does always return the same error:
```
Easypost returned an error:
Unable to proceed, 'customs_info' is required for
international shipments, shipments bound for US
military bases, or US territories. Please see
https://www.easypost.com/docs/api#customs for more information.
```
After this commit:
As no commodities were set, `_customs_info` will return
an empty dictionary.
To solve that, we set the `DeliveryPackage` commodity
value on its initialisation to compute the customs
information the way it should.
opw-3104305
closesodoo/odoo#112988
X-original-commit: 06beca4373743787ae629b2c7ea623bf0583727a
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit, the widget's description was stored on the
component and this component was then registered.
Now, an object describing the widget is used on registration the same way
as it is done for views since b828cfc.
This split the component's description (props, template, ...) of
the widget's description ( component, extractProps, ...) and makes
it clearer.
We did the same thing for fields in 9f4622492c
Part of task: 3179751
closesodoo/odoo#112962
Related: odoo/enterprise#37215
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the email added to the blacklist was the value
of the email after the deactivation of the user.
It may lead to blacklist the wrong email when the deactivation change the
email
after this commit, like phone number, we keep the value of the email
prior the deactivation which the real email to blacklist
closesodoo/odoo#113187
X-original-commit: db85db81df57da87c57171fa2d5009eb097f2903
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Problem:
In a list view, editing a record and then clicking an action button
on that record does not save the edited field values.
Expected behaviour:
Changes applied to the record must be saved before executing the button
action.
Solution:
The 46bd694c8a67f25470a911c1eb04e0bf2e17a5f7 commit in master solves
this problem (TaskID-3132960). We will backport it and add a test for
our use case.
How to reproduce:
- Go to a list view with one text field and one button action per record
- Edit the text field
- Click on the button action
Before this commit:
The value of the text field has been restored. We lost our modification.
After this commit:
The record has been saved.
closesodoo/odoo#113120
Taskid: 3168517
X-original-commit: 5f5040730707e62885757aa6a39345a46cda9b48
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
The kiosk's PIN mode was only accepting codes entered using the keyboard
shown on screen, dismissing keys entered on a real keyboard.
task-3127253
closesodoo/odoo#112922
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The specific classes used to render the trigger icon should be as
localized as possible (not used in js and xml if not necessary).
We also take the opportunity to simplify the widget `state` items.
At this occasion, we also eliminate the flicker that could occur
with the icon of a triggered question when deleting its trigger.
Task-3151916
closesodoo/odoo#113168
X-original-commit: 5ce6915e66673b7d88363676473154c3ec8fd3aa
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Following this flow on the Media Dialog:
- Type "hell"
- Wait a few ms so that the RPC to search images starts
- Type "o"
- The RPC of before finishes, the o is removed and no new search is done
Before this commit, the search input value of the SearchMedia component
was coming from a "needle" props. This needle prop was a state on the
parent component (FileSelector), set through a debounced handler.
This is not a good design:
- Type "hell": after 1000ms, the debounced handler will be executed with
the value "hell"
- While the handler is executing: type "o"
- When the handler finishes, it has set the needle state value to "hell"
on the parent. This will rerender the SearchMedia with "hell" as a
needle prop, and the "hello" input will be replaced with "hell".
Instead of doing that, the SearchMedia component should have its own
input state, which models the input element.
On that state, we use an effect to call the debounced "search" callback.
This way, the SearchMedia is less dependent on its parent: it only
rerenders when its input element changes.
Additionally, the fetch results are only used if they are the ones from
the last call to `search`.
Dedicated `KeepLast` instances are used for attachments, media library
and unsplash.
task-3060679
closesodoo/odoo#113188
X-original-commit: 08859ca7939454303e34dc39c831ac8f75773c3d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Arthur Detroux <ard@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
Since we create a google meet link when we create an event, we get an
issue with the appoitments that generate their own videocall links. That
lead to send a Odoo discuss link to the customer, and then set the
google meet link in the sales person calendar.
As the insert of google event is done post commit of the transaction,
and there is no way to generate a google meet link before the creation
of an event, there is no trivial fix to generate the google mette link
at the right moment. We just don't generate the google link when a Odoo
discuss link is already there.
closesodoo/odoo#113192
X-original-commit: 1a1a8e48995cfe37a0c8536bbcfc3341d76499ef
Signed-off-by: Masereel Pierre <pim@odoo.com>
In the sample server, we generate random float values between 0
and 100. The faulty assertion expected the value to be strictly
less than 100, however, it sometimes failed: when Math.random()
generated a value >= 0.99995, it produced 100 as float value.
Runbot error 15206
closesodoo/odoo#113181
X-original-commit: 4abfb9553559080d53bc5a8ba521eec000c56a26
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
The sample server did not create a __range value when grouping by 'date'
This resulted in a traceback as it is expected to at least be false.
This commit computes it properly.
task-3098681
closesodoo/odoo#113163
X-original-commit: cf074f1dc01da39e75aa30e4ac21eafa29d528d9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the "create" function of the ORM service didn't
allow to pass multiple records. As a consequence, it was needed to
create records one by one calling the ORM create multiple times or call
create via the method call.
This commit allows to use the create method to create several records at
once.
closesodoo/odoo#111965
Related: odoo/enterprise#37290
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The previous commit has as a side effect to change the value returned by
the create method of the orm service. Here we adapt the code that uses it
and make the test pass.
Part-of: odoo/odoo#111965
Before this commit, the "create" function of the ORM service didn't
allow to pass multiple records. As a consequence, it was needed to
create records one by one calling the ORM create multiple times or call
create via the method call.
This commit allows to use the create method to create several records at
once.
Part-of: odoo/odoo#111965
Before this commit, the reserve and unreserve buttons did not appear
for MOs.
Another bug was also fixed, removed the 0 Inventory on Hand line that appeared
when there are no moves in the report.
closesodoo/odoo#112981
Signed-off-by: Steve Van Essche <svs@odoo.com>
Commit[1] intended to change the color of links in the editor to make them more
visible by making them a slightly lighter color. However, it did so in a way
that also applied to button links, which already had different colors. In the
case of primary buttons, it actually made the links less readable as a result.
This commit excludes buttons from the original css rule so that they keep their
special style while still maintaining the intent of the original commit.
[1]: 47c73c7213
task-3131568
closesodoo/odoo#113141
X-original-commit: a40bca916ac17338d82c52afd7c0eedd96d4a49d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Current behavior:
When using a language with a comma as decimal separator, the cash in/out
popup wouldn't allow you to enter a "," in the input field
Steps to reproduce:
-Install a language with a comma as decimal separator (e.g. French)
-Open a POS session
-Click on the cash in/out button
-Input doesn't allow you to use comma.
This is not linked to any ticket, I found it while testing the POS.
closesodoo/odoo#113111
X-original-commit: 865513a90713e8486d5bf0c5a547acedab3bd285
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Traceback happens because it doesn't require records and call the
function without row records. The code doesn't handle that case.
Don't try to find unavailabilities in that case and just skip this
part of code
closesodoo/odoo#113104
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit, creating a link through the link tool made two
steps instead of one.
task-3147819
closesodoo/odoo#113135
X-original-commit: d967c21b6abdccd45f3c767925de29e874497dd4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when discarding a link in linkDialog, there was a
link and a history step that were created. We now properly come
back to the state of the editor before the linkDialog was opened.
task-3147819
X-original-commit: 79205c8df555d7194d4a8a0ad4f04a9f7dc7f535
Part-of: odoo/odoo#113135
When clicking in a link in the forum, the link dialog was opened.
This is wrong as there the link popover is shown and to open the link
dialog, we must click on the button in the link popover.
task-3147819
X-original-commit: 5c5aa21dffe3691547766cf1f16065ae74c41f07
Part-of: odoo/odoo#113135
For performance reasons, we added a feature that allows to limit
the search_count done when fetching records in list and kanban
views, to display on the right side of the pager [1][2]. However,
the page previous case wasn't correctly handled when we had a
limited count. When doing page, we need to know the total number of
records to compute the offset. Before this commit, we went to the
last page, which wasn't really the last page (because we sent a
wrong offset), which can be misleading for users. With the commit,
we force a search_count when doing page previous on the first page.
[1] 6acfad2651
[2] 699215ec9a71b8c9b6a53fe96e924a400d216729
Task 3162026
closesodoo/odoo#113134
X-original-commit: cefff0dcd5b3b1120b215e6af28d678c7ec34d52
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Since commit [1], we can have list or kanban view with same limit
and count_limit (to save a costly search_count), i.e. have a pager
like "1-80/80+". Before this commit, when reaching the count limit
on page next, we performed the search_count. This was fine before
as the count_limit was hardcoded to 10k, so you basically never did
page next until the limit. However, it's a issue now that the
count_limit can be specified, as in the above example, we don't
want to slow down the loading of the second page records because of
the search_count.
With this commit, we slightly increase the count limit when we
reach it, so for instance doing next when the pager shows 1-80/80+
fetches the records with args offset=80, limit=80, count_limit=160
and the pager then shows 81-160/160+. If the total number of records
is reached, we know the count and display it, for instance, after
another pager next: 161-190/190.
The same logic applies when the pager is manually edited, e.g. when
you write 1-150 in a pager showing 1-80/80+, you'll get 1-150/150+
if there are more than 150 records.
[1] 699215ec9a71b8c9b6a53fe96e924a400d216729
Task 3162026
X-original-commit: d39559274e6de6cdba6972775f9bda8bd2de8fa6
Part-of: odoo/odoo#113134
roen-odoo