Steps to reproduce:
In Working Times, click on "SWITCH TO 2 WEEKS CALENDAR"
for the default calendar used by the company.
Issue:
A ValidationError appears: 'Attendances can't overlap.'
Cause:
To create a two-week schedule, by default,
we will use attendances provided for the company's default schedule.
When we want to switch from a one-week schedule to a two-week schedule,
we first delete the attendances from the schedule to be modified.
However, if this schedule is the company's default schedule,
it will no longer have the default attendances
that we must use to build the two-week schedule.
So we end up with the two "fictitious" attendances
that are used to delimit the two weeks.
With only these two attendances, the constraint of not having
two overlapping attendances is not respected
(because the two attendances created will be modified
to belong to the same week).
Solution:
Check that the calendar to be modified
is not the default calendar used by the company.
opw-3127337
closesodoo/odoo#112912
X-original-commit: 2f56ffbc2f1d3a2afbf51a859a5a5730af06fd6f
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, if there were no selection in
`_handleSelectionInTable` because the document was removed (in case the
document was in a removed iframe), the method would crash.
task-3052658
closesodoo/odoo#112908
X-original-commit: 8e23a4191730d5512c9de81c23f8e4e88e99ddb1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, `commitChanges` was inlining even when the content
did not change. For instance, this event was called on every change of
the record through the "next record" button of the form view.
As toInline is computationally expensive, this commit execute it only
when necessary (i.e. when the content is dirty).
When there is a save action that is triggered in mass mailing (eg.
through the button, breadcrumb, urgent save), if a previous call to
`commitChanges` is still in progress, the inline field migth not be
saved, thus we need to wait for a pending promise.
task-3052658
X-original-commit: 3d43d462758c3c9b3817a7c19ccd88517f8625e1
Part-of: odoo/odoo#112908
Before this commit, openning a mass mailing tried to load an image
that was not present in the module, where the server took some
seconds to respond, slowing down the openning of the mailings.
task-3052658
X-original-commit: d80ed2814730f0074f2c5acf56ca385f6b9513e6
Part-of: odoo/odoo#112908
Before this commit, some operation (eg. move node, duplicate or remove a
snippet from the snippetMenu) in the snippetMenu sidebar did not
trigger the mass mailing commit changes and therefore if no selection
was made in the document followed by a blur was made, no changes could
be recorded and saved by the owl form component.
task-3052658
X-original-commit: 8bd8db97ee0d7774e5aa0495b9a5cc7d695fca67
Part-of: odoo/odoo#112908
When the debug assets option is not activated, the assets are rendered
with a space being trimmed from a string notation using backtick.
This fix, uses the single quote notation to avoid this issue in
`wysiwyg_iframe`. Without that fix, the structure of the dom is wrong
and causes css rules to not be applied.
task-3100202
X-original-commit: c54fcf21aecccac20b2c1d781132ed67df6c20a7
Part-of: odoo/odoo#112908
Before this commit, the sidebar visibility was toggled with a css
transition, each time a change was made in the html_field.
Additionally, the transition was not working properly when opening
a mailing. Because this transition was made for website and this code
is no longer being used in website and is not usefull for mass mailing
we can remove it.
task-3100202
X-original-commit: 21056444562e530fb811095b4805345709295ca3
Part-of: odoo/odoo#112908
In mass_mailing, when there is an element with a background image, the
method html2canvas is used.
On a Mac M1, rendering that snippet takes ±700ms per element that goes
into html2canvas.
The reason is that html2canvas clone all the document of the node that
is passed to html2canvas. This is the document of the mass mailing
iframe (for instance including the snippet menu).
As a rendering is called at each input change in the editable
(eg. editor blur, adding a snipet, ...), the main thread will be blocked
more than 700ms each time the input change.
The reason it is slow is because html2canvas is cloning the whole
document, in order to properly get the style of the targeted element.
Because the element style is already inlined by the to_inline, this is
not necessary to clone the whole document.
In order to make html2canvas instantaneous without changing the lib
source code, the solution is to render from another iframe that
contain only the element to render.
task-3100165
X-original-commit: 8ea22ea04e4d7108ba6920fed3e1898df28a53d8
Part-of: odoo/odoo#112908
Since we use `historyRevertCurrentStep` in `commitChanges`, the tour
`mass_mailing_editor_tour` break because the dropped snippet was
removed on save. We need to wait for the step created by the drag and
drop stop method (when `o_we_already_dragging` is removed).
task-3052658
X-original-commit: 2d09c9663a0e6b44927f0b74235973a1925d3e22
Part-of: odoo/odoo#112908
This commit fixes two issues:
If the user click on a form tab (e.g. A/B Tests) before `toInline`
finishes, `toInline` would not be able to work properly. The reason
is that a parent element is being removed by owl when changing tab.
Similarly, changing the view from the breadcrumb could save a wrong
version in body_arch as the `toInline` could not fully finish because of
the same reason (a parent element being removed).
To solve that issue, this commit inline the `body_html` from another
iframe appended in the body.
This fix also ensure:
- no stale state for the body_arch
- no dependency of owl rendering lifecycle
task-3052658
X-original-commit: f429e8465adcddac5a24d8e178b39f1d20bfe15c
Part-of: odoo/odoo#112908
This commit's purpose is to allow the creation of timesheet even if the
analytic account of the project has no company_id
closesodoo/odoo#112906
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Current behavior:
When importing an order from the sales app in the PoS app, there was a
text showing the "Old price" of the order line. But the actual price
and the Old price were the same.
Steps to reproduce:
- Install the l10n_fr_pos_cert module
- Install the pos_sale module
- Create a sale order
- Open a PoS session
- Import the sale order in the PoS session
- The order line is showing an "Old price" when it shouldn't.
opw-3130969
closesodoo/odoo#112903
X-original-commit: e34c0fb8a51d15176752a1c5526673cf26deadab
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
This commit fixes an issue where the "No records found" helper text is
wrongly positioned below the sample data's records (i.e. not visible)
instead of over them.
This is basically a revert of 9407383a56
due to the changes in the DOM and styling made in the meantime.
But actually we can go further and ensure we always have the ListView's
table present in the DOM. This change allows to simplify the positioning
of the helper and the implementation of the Purchase's dashboard.
Steps to reproduce:
- create a new database **without demo data**
- install "Planning" and "Sales" apps
- with a mobile-like screen size, open Planning
- switch to Gantt view
- in a cell, click/tap on the magnifier button (which is on hover...)
- the many2x view doesn't contain data
=> action helper "No records found" isn"t visible (scroll to bottom to
find it)
closesodoo/odoo#112878
X-original-commit: 766498a36b322ffe9c647616f56f3ba04cc51d96
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Let us have records with values 1, 0, 77, 3 for a float field 'foo'.
read_group allows to get those values in an array with the aggregate
function array_agg:
read_group([], ["foo:array_agg", ...], []) will return
[{ __count: 4, foo: [1, 0, 77, 3], ... }]
We now support the use of array_agg for integer and float fields in
the mock server.
closesodoo/odoo#112825
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
mockReadGroup should not count the value false for a many2one when
aggregating a many2one field with the aggregate function count_distinct
and should always return a number. We fix that.
Part-of: odoo/odoo#112825
Let us have records with values false, 1, 2, 1, 1 for a many2one 'm2o'.
read_group allows to get those ids in an array with the aggregate function
array_agg:
read_group([], ["m2o:array_agg", ...], []) will return
[{ __count: 5, m2o: [null, 1, 2, 1, 1], ... }]
We now support the use of array_agg for many2ones in the mock server.
Part-of: odoo/odoo#112825
-The stock valuation, input and output account were wrong. Now correct accounts are set
-Removed the 6% VAT. Is not used for years now in the Netherlands. It is now 9%
-Removed the "BTW overige" for sales/purchases within EU and outside. These taxes do not exist. "BTW overige" is only domestic
-Renamed 'EU landen privaat' for better name B2C (that is what it is used for)
-Added valid TAX Identification number on company
-Changed the state to a state within the Netherlands and not in the Dutch Caribbean
closesodoo/odoo#112493
Signed-off-by: John Laterre (jol) <jol@odoo.com>
This commit is a refactoring of the domain selector to simplify it.
The component DomainSelector now uses less sub components.
Consequently, the code is centralized in fewer files and more readable.
closesodoo/odoo#110978
Task: 3149707
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Following up https://github.com/odoo/odoo/pull/112692 that avoided the use
of the 'Number' javascript function in the 'product_discount_field' widget, the
call to that function was left in the code. It is useless and can be removed
since the value of the new field used, the property field 'props.value', is
already a float.
closesodoo/odoo#112891
X-original-commit: fb8b217f8bd2323d33bbeb949f35cd1620557960
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
`handle_error`'s docstring states that it returns a `Response`, but in most case `HttpDispatcher.handle_error` returns an `HTTPException`.
After discussion, the implementation is correct, `handle_error` should be documented to return a WSGI Application (a callable taking an `environ` and a `start_response` callable) instead.
closesodoo/odoo#112889
Forward-port-of: odoo/odoo#112690
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If you have a lot of attendance spread accross various employees and various dates,
the report takes ages to load (or your browser freezes and you can't access reporting).
And if it loads, the report is unreadable anyway. Use a default filter to always
display user friendly graphs. Since we group by day, a default period of a month seems
like a good compromise.
To reproduce the issue:
- install hr_attendance
- use a script to create some attendances (ex: create 300 employees and 30
attendance for each, spread randomly in the last 3 years)
- click on "Reporting"
opw-3167099
closesodoo/odoo#112879
X-original-commit: 59bf5d4c5e7c95c6f561140f71634d84a12568a0
Signed-off-by: Kevin Baptiste <kba@odoo.com>
To be able to compute the taxes offline, the POS JS code mimicked the
`compute_all` function in `account_tax.py`. At some point, the POS added
an extra field on `account.tax` (see:
https://github.com/odoo/odoo/commit/8fb53c53c3128e8cea7ef20b9ab4946ac2f9b7d9):
`real_amount` which is defined as:
real_amount = tax.amount * sum(tax.repartition_line.factor)
Then, when fetching the data from the server to the client, the
`real_amount` was passed in place of the `amount`.
But then, the `amount` field in the JS is no longer the same as in the
python code and it is very error prone. In addition, it's easy to get
rid of this extra field by using the sum of the factors from the
repartition lines.
Now, we pass the sum(tax.repartition_lines.factor_percent)/100, which is
equivalent to sum(tax.repartition_line.factor) to the client, and use it
in the `compute_all` as done in the python function, and leave
`tax.amount` untouched.
Both `compute_all` functions now operate using the same `tax.amount` and
we get rid of the `real_amount` field.
closesodoo/odoo#112063
Related: odoo/upgrade#4307
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When validating a confirmed picking, if in the meantime the user
added an SML with a kit, the done picking will have some not-done SM
for each kit component.
To reproduce the issue:
1. Inventory > Operation Types, edit Receipts:
- Show Detailed Operations: True
2. Create three products:
- P_kit
- P_compo
- P_other
3. Create a kit BoM
- Product: P_kit
- Components: P_compo
4. Create a planned receipt R
- Operations:
- 1 x P_other
5. Mark R as todo
6. Add two detailed operations:
- 1 x P_other
- 1 x P_kit
7. Validate R
Error: The SM for P_kit has been replaced with its component, which
is correct. However, the done quantity of the new SM is 0, it should
be 1
At some point, because the done quantity of SM_kit is gerater than
the demand, we create an extra move:
https://github.com/odoo/odoo/blob/24f2e3f73498e5eb180a6793de6c25efd414aadb/addons/stock/models/stock_move.py#L1529-L1534
So, the goal is to create a second SM_kit_02 with the expected
demand. Then, we merge this new SM_kit_02 with SM_kit:
https://github.com/odoo/odoo/blob/24f2e3f73498e5eb180a6793de6c25efd414aadb/addons/stock/models/stock_move.py#L1491-L1493https://github.com/odoo/odoo/blob/5f8da70b5b1f313e9b676846e55e84621f55e734/addons/mrp/models/stock_move.py#L239-L242
As shown above, we explode SM_kit_02 which gives SM_compo. However,
we don't explode SM_kit. Thefore, we will not be able to merge
SM_compo with SM_kit. In such situation, we should also explode
`merge_into`.
For the explode method to work with SM_kit, we need to change few
lines: as said at step 4, the receipt is not an immediate one.
However, we still have a case here where the SM has a quantity done
without any demand and only the done quantity matters (as we are
validating the receipt)
OPW-3015933
X-original-commit: 35a5b83b93fceac4073689edd74d680bed09a143
Part-of: odoo/odoo#112814
When manually setting a discount on the first line of a sale order having more than 3 displayed lines, the product_discount_field widget prompts the user if he would like to apply the same discount to all the lines.
This fails to apply when the localization uses a comma as decimal separator instead of a dot or uses a digit grouping symbol. This is because the widget calls the JS function Number() on the string that was entered by the user in the discount field, after it was formatted according to the localization.
Taking the number 1500 as an example, different cases are:
- Number("1500.0") gives 1500
- Number("1500,0") gives 'NaN'
- Number("1,500.0") gives 'NaN'
- Number("1.500,0") gives 'NaN'
This result is then used to apply the discount on the remaining lines of the sale orders. Using 'NaN' will result in a 0% discount.
The use of Number() can be avoided by using the property field 'value' of the product_discount_field widget.
opw-3127690
closesodoo/odoo#112734
Forward-port-of: odoo/odoo#112692
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
By adding an explicit order to the queries within `existing_accounting` the PostgreSQL query cost drops to `cost=0.84..1.78 rows=1 width=4` from `cost=13061.20..18895.19 rows=1 width=24` (on my local dev machine).
closesodoo/odoo#112842
X-original-commit: ab34d6b0273c6766757f0596ca5f62458a9d5ab5
Signed-off-by: John Laterre (jol) <jol@odoo.com>
The date from would not be formatted on leaves spanning multiple days.
closesodoo/odoo#112830
X-original-commit: 7a392e9af999084d9dddf0f82affd6d539f5d907
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Werkzeug 1.0 colorised some outputs on POSIX IFF `click` was
installed.
Since 2.0 (pallets/werkzeug#2012) werkzeug unconditionally colorises
the log on POSIX. This is annoying when using output redirection (let
alone logging to a non-stream), as werkzeug will dump ANSI color codes
to the non-term stdout and thus the logfile.
Werkzeug provides no official knob to control this behaviour, but it
does have a secret flag which is normally used to check if colorama is
available on windows (so the ANSI codes are not output if colorama
won't be interpreting and stripping them on the way out). Since
`werkzeug.serving` is available in pretty much all versions, we can
just (un)set this flag if not logging to a tty, and versions 2+ should
pick it up and disable colorisation.
closesodoo/odoo#112829
X-original-commit: 7c9f883dc508a7a8a45bf7bf7e900da0be9b34be
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
*: base, http_routing, mass_mailing, web, web_editor, website_slides
In some situations `werkzeug.wrappers.Response` are used instead of
`odoo.http.Reponse` that extends it.
This is a problem because since [1] the calls to `set_cookie` expect it
to accept the `cookie_type` parameter, which is not the case in the base
werkzeug implementation.
This commit replaces the `werkzeug.wrappers.Response` by
`odoo.http.Response`.
[1]: https://github.com/odoo/odoo/commit/2cbda6c98ee947cea1d06c09880eee8c758304a8closesodoo/odoo#112827
X-original-commit: 28da08292b7028575e628c5ad846fc05d30498f2
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Since commit (1), the write/writeText were no longer correctly called,
because the browser native functions couldn't be called. Sometimes, it
raised the "Illegal invocation..." error, or could have an unexpected
behavior, preventing the value to be copied in the clipboard, which made
the button pointless.
No additional test was added, since it is difficult to test the clipboard
API programmatically, and the current test coverage is all that we can do,
without using the real clipboard object.
(1): 9cdcd1c1f7219030386d2c90205ea083eb835a13
closesodoo/odoo#112843
X-original-commit: 767922d43334a6cbccdb4be64f207813240fd314
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
repro steps:
1) in any kanban view that is not grouped, use the arrow key to focus the last card
2) use the up key to focus the previous card
3) use the TAB key to focus any element inside that card
4) use the down key to try to navigate to the last card -> traceback
The error comes from the fact that `focusNextCard` assumes that the
focus is exactly on the card element and not on any of its children.
closesodoo/odoo#112797
X-original-commit: 76434f4959cd0fade41ad02f790226f1a8046fea
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit removes the legacy CustomCheckbox and the backward
compatibility layer for the systray items. Both of them are no
longer used.
closesodoo/odoo#112718
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit fixes the wrong label that was displayed when options
are defined inside groups. Since displayValue was only looking for
a label on choices set using the choices props, the getter was only
returning the technical value for choices defined in groups.
A test has been modified to verify that the correct label is shown,
also on choices present inside of a group. This test previously
asserted that, but only on choices given by the choices props.
closesodoo/odoo#112766
X-original-commit: 176e61d5c25111a1e9339a0687bb526d1d430790
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
Bug
===
The unlink of the <mail.mail> in the CRON is problematic because we
accumulate a lot of records, and the CRON timeout.
In particular, when we sent a mailing, we receive the "opened" event
(blank image in the email), and so we need to update the mailing trace.
But, if we unlink the mail at the same time, it locked the mailing trace
table and we couldn't write the new value.
The reason for that is that before, the unlink took more queries, but
it was done one record at a time, so we could commit the change and
release the lock between each unlink.
Task-3179157
See odoo/odoo/pull/73271
closesodoo/odoo#112331
Related: odoo/upgrade#4320
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The PR #105579 introduce the call of `setupCollaboration` in
`resetEditor` but did not remove the instructions in `resetEditor`
that will be called in `setupCollaboration`.
`this._getNewPtp` should be called by `setupCollaboration` as it is
called after an asynchronous call.
Additionally, `this._peerToPeerLoading` has to be awaited to prevent
concurrency issues.
closesodoo/odoo#112253
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
With this commit, we add the shipping address
to the invoice report when it is different from
the invoicing address.
We do the same way as in l10n_din5008_sale/models/sale.py
and l10n_din5008_purchase/models/purchase.py,
by adding the computed field l10n_din5008_addresses
in account_move.
Steps:
- Insltall l10n_de and sale
- Set Customer addresses in settings
- Ensure that DIN5008 is set as document layout
- Create and confirm an invoice with delivery
address different than invoicing address
- Print or preview invoice
-> Shipping address does not appear on report
opw-3090418
closesodoo/odoo#112740
X-original-commit: 36731269ccd4ae8ca6d6078f7f9d6760381a5beb
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Bug
===
The unlink of the <mail.mail> in the CRON is problematic because we
accumulate a lot of records, and the CRON timeout.
In particular, when we sent a mailing, we receive the "opened" event
(blank image in the email), and so we need to update the mailing trace.
But, if we unlink the mail at the same time, it locked the mailing trace
table and we couldn't write the new value.
The reason for that is that before, the unlink took more queries, but
it was done one record at a time, so we could commit the change and
release the lock between each unlink.
Task-3179157
See odoo/odoo/pull/73271
closesodoo/odoo#112703
X-original-commit: 57ae1b9b8b61f5f4719a8a81e9d0d21fab58cfda
Related: odoo/enterprise#37069
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Steps to reproduce the bug:
- Get the website module.
- Go to Settings > Website > Shipping.
- Activate "On Site Payments & Picking" and save.
- Go to the same setting again and click on "Customize Pickup Sites".
- Pick the only delivery method that exists.
- Inside the delivery method, select a warehouse of the current company
and try to save.
Issue:
We won't be able to add a warehouse as the hidden field of the
`company_id` is not set.
Solution:
We modified the if statement inside `_check_warehouse_company` in order
to accept companies.
opw-3097424
closesodoo/odoo#112696
X-original-commit: dc8c24a5ace17382f54ad256b0ef585e24bca7ca
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The redirect function in the router exists only for the wait option.
This option is only used in one case (client action home). We have
therefore decided to remove the redirect function and to call
browser.location.assign(...) directly.
We will also remove the "wait" param for the "reload" and "home"
client actions. Because no call to "reload" needs it (1) and all calls to
"home" want it wait=True. So we will move the code that was executed
if wait=true to the "home" action client.
(1) In the POS, wait=true is used for a "reload" but this has no impact.
Wait=true was intended to wait for the server to restart before reloading
the page. In the case of the POS, there is no restart of the server, so
wait=True is useless.
closesodoo/odoo#112621
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, the resize behaviour and the draggable behaviour were
completely separate, even though a lot of the logic for both behaviours
is common to both. This commit replaces both of these behaviours with a
hook: useMovable that lets the user drag an object around, but lets the
caller customize the behaviour on drag: when dragging a table or the
debug menu, we want to move the object around by setting its position in
its container, but when dragging a resize handle around, we want to
resize the table while keeping the handle position in the table the
same.
This commit also makes a bunch of popups non draggable as it doesn't
make sense for them to be draggable: you cannot interact with the
content behind the popup for as long as the popup is open (unlike the
debug menu), and serves no functional purpose, and may occasionally
confuse users.
closesodoo/odoo#112610
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Some changes were made to the default/demo/test data to be more
consistent:
- Duplicates of "Paid Time Off" time off types are consolidated into
one type (inluding year specific versions, ig "Paid Time Off 2019"
- Annual Time Off is renamed back to Paid Time Off (both for the
work entry type as the time off type) to be consistent everywhere.
- All mentions of years in work entry types and time off types have
been removed, as this is no longer relevant with the new allocation
rules.
- Time off types in the default data have been explicitely made
company agnostic, in order for them to be available to all companies
and not just the one company that was select when installing
hr_holidays. This was already the case for the be_payroll data, but
not for the standard hr_holidays ones.
- Various small cosmetic / functional fixes and simplifications
(eg deduplication of data)
- expense_other_input has been made country agnostic, in order for it
to be available in all countries.
task-2978513
closesodoo/odoo#112208
X-original-commit: dcc8bbf
Related: odoo/enterprise#36819
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, when obtaining link URL suggestions, both the
specific and the matching generic page were suggested.
After this commit, only the most specific ones are kept in the suggested
list.
This commit also adapts the sitemap in the same way.
In stable, a condition on a dedicated context key is used in case those
methods were called with the goal of obtaining both generic and specific
pages.
In 16.0, those methods will always filter duplicates pages as it was
supposed at first.
Steps to reproduce:
- Edit Contact Us page (to create a specific view)
- Edit the Contact Us menu
- Type "/" in the URL
=> "/contactus" appeared twice.
task-2968292
closesodoo/odoo#112746
X-original-commit: c5a50362ef55ced373c53c7af069fd5534043ae2
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Thomas Lefebvre (thle)