When NumpadDecimal is triggered, appending the decimalPoint to the
input field value is not enough, rather, we should replace the selected
range.
Also, we should ignore this for input field of type="number" because
it's natively taken into account.
X-original-commit: 3389cd2226ec82df9aa015637ac2d6a405936a4a
Part-of: odoo/odoo#104114
This commit fixes the account_accountant demo tour.
Some attributes in the html have changed and the reconciliation widget was refactored.
Fix the broken account_tour_upload_bill view.
Fix the test of account_accountant_tour (missing import in __init__)
closesodoo/odoo#104110
X-original-commit: 8414a5a77be5fbcc6f66ba2acf160f43748c891e
Related: odoo/enterprise#33210
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Our current version is getting rather outdated. Replace by the *legacy* bundle: pdfjs now provides a non-polyfilled version of the library, which is probably faster though it doesn't save overly much (for the entire bundle anyway). Use polyfilled version for safety, though it's unclear whether non-chromium Edge is still supported by Odoo. If not, we could just use the non-polyfilled version.
The difference is quite large for pdf.js (+32.5%), however it is much less consequential for the sandbox (+1%) or for the much larger worker (+5.6%). The biggest difference is likely performances but... who knows?
Notes:
- The main reason for this change is that automated vulnerability scanner have apparently started scanning for `postMessage(..., '*')` and the previous bundles includes a version of corejs polyfills without zloirock/core-js#542), therefore triggering those scans. As the PR notes this is almost certainly not a concern because of the innocuous payload, but there is no reason to waste time on those reports if we don't *have* to.
- The bundle now includes "standard fonts", those were removed as they're heavy and may not be necessary for our usage (?).
- All the bitmap images were dropped and replaced by svgs, which is nice.
- Previously local / bespoke changes:
- 32c8922432 DOM dispatching has been removed, hook into pdfjs's event system
- 2d5dd1448f seems to be the default now
- 74fa91e0b3, re-apply change in default configuration
- pdfjs has migrated from lots of its objects / operations being / returning promises, to the result objects containing promises, this has required quite a few adaptations in website_slides
closesodoo/odoo#100067
Related: odoo/enterprise#31692
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Reimplementation of 74fa91e0b3 on top of
new version of pdfjs. See previous commit for explanation.
Ideally we would set that behaviour from the outside using
e.g. `PDFViewerApplicationOptions.set` but there are multiple
locations from which we embed the viewer, which makes that a difficult
proposition. There should probably be a clean component which handles
loading the library, configuring it to our specifications (possibly on
a per-embed basis), and exposing both manipulations methods and events
which pdfjs triggers on its eventBus.
Part-of: odoo/odoo#100067
Apparently a PDF Document used to *be* a promise (a "thenable") but
that's not the case anymore. The loading promise has to be deref'd
explicitely. This is also the case for `page.render`, which is not a
thenable anymore.
Furthermore, the API seems to have changed to favor parameter
objects (getViewport) and setting callbacks (onPassword) rather than
having lots of positional parameters.
Finally, remove apparently long dead `disableWorker` feature in
`PDFSlidesViewer`, although really the entire thing should be
rewritten in modern javascript.
Part-of: odoo/odoo#100067
Our current version is getting rather outdated. Replace by
the *legacy* bundle: pdfjs now provides a non-polyfilled version of
the library, which is probably faster though it doesn't save overly
much (for the entire bundle anyway). Use polyfilled version for
safety, though it's unclear whether non-chromium Edge is still
supported by Odoo. If not, we could just use the non-polyfilled
version.
The difference is quite large for pdf.js (+32.5%), however it is much
less consequential for the sandbox (+1%) or for the much larger
worker (+5.6%). The biggest difference is likely performances
but... who knows?
Notes:
- The main reason for this change is that automated vulnerability
scanner have apparently started scanning for `postMessage(..., '*')`
and the previous bundles includes a version of corejs polyfills
without zloirock/core-js#542), therefore triggering those scans. As
the PR notes this is almost certainly not a concern because of the
innocuous payload, but there is no reason to waste time on those
reports if we don't *have* to.
- The bundle now includes "standard fonts", those were removed as
they're heavy and may not be necessary for our usage (?).
- All the bitmap images were dropped and replaced by svgs, which is
nice.
- The local changes since the previous update were *not* impacted in
this, the entire thing was just reset to upstream. This means
changes which were backported (922c7c72, 6943714f) are superseded
but more odoo-specific changes will have to be reapplied in further
commits.
Part-of: odoo/odoo#100067
There was too much padding up and down from the tooltip.
Adds conditional display on the template menu
when there are no templates (t-for-each is not fully empty).
Also fixes the favorite icon color in edit mode.
task #2984478closesodoo/odoo#104108
X-original-commit: a170b7265e158323d3769f1631314f06c96a6e4b
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Probably since recent changes in the views architecture, and
because the test coverage was recently extended, this test
failed when l10n_mx_edit module was installed.
While verifying the current user has access to all the fields specified
in the settings view, we browse all the fields, including the ones in a sub-view:
<field name="x_ids">
<tree>
<field name="whatever">
</tree>
</field>
x_ids being a settings field, but not whatever, which made the test fail.
To fix this problem, we check the fields belong to the res.config.settings
model before trying to access it.
closesodoo/odoo#104119
X-original-commit: 60f22b71063eada039f59321722e794c653acbde
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since the form view has no longer a readonly mode, the task name could
be cropped since its size has been reduced in a previous commit to keep
the same size in edit mode in 15.3 (before the OWL conversion and the
always edit feature). This behavior is no longer expected and the size
should be the one in readonly mode to use the available spaces between
the task name and the kanban state.
It is for this reason, this commit reverts
74a069226294044fa8901aed6b02bc25c4e11b21.
closesodoo/odoo#104118
X-original-commit: 677c8b1bc60fe0736ce45e8c041a03e65fc6413c
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
A Payroll Manager couldn't access the work entries of their own
employees as they couldn't write the work entries generation date on the
employee's contract.
task-3014915
closesodoo/odoo#104113
X-original-commit: d6a5909f988568581c2ec5b3f83271863be85fc4
Signed-off-by: Kevin Baptiste <kba@odoo.com>
PURPOSE
Extend implementation of ``phone_mobile_search`` that is currently limited
to performing an ilike with a term containing at least 3 characters. Any
operator is automatically considered as being an 'ilike'.
SPECIFICATIONS
Correctly support boolean check (is set / is not set), with its own small
implementation easier than the remaining computation.
Correctly propagate operator in generated SQL: like, ilike, =, those operators
should not be automatically considered as always ilike.
Correctly support negative operators. Supporting only positive search is a
bit limited.
Add tests.
Task-3012789
closesodoo/odoo#104111
Forward-port-of: odoo/odoo#103354
Forward-port-of: odoo/odoo#100724
Related: odoo/enterprise#33211
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently the search method defined on 'phone_mobile_search' supports either
a boolean (is set / is not set) search, either considers all searches to be
"like TERM". This is coming from the main usage that is the search view
that sends domains like "[('phone_mobile_search', 'ilike', term)]".
In this commit we improve the method to correctly support
* direct check (=)
* negative operators (not (i)like)
* like / ilike (previously like were considered as ilike)
Idea is: a positive operator check that any of the phone fields respects the
domain (phone or mobile is TERM). A negative operator checks that all phone
fields respects the negative domain (both phone and mobile do not contain TERM).
Tests are added.
Task-3012789
X-original-commit: 8e905343f38a4dae828ccaddc62ce5c6a2f754db
Part-of: odoo/odoo#104111
To reproduce
============
Go to Contacts and try to filter by phone/mobile is/not set. A traceback is
raised.
Problem
=======
The search method responsible for this field didn't take into account Value
to filter by to be a boolean.
Solution
========
Correctly support this case in search method.
Add unit test.
Task-3012789
opw-2980542
X-original-commit: 62b7da527c6ddb4654fbccf5c6d8c94158915ebc
Part-of: odoo/odoo#104111
Currently the search methods defined on ``phone_mobile_search`` field forces
the usage of ``phone`` and ``mobile`` fields on model. This currently works
on models using by default this search field (lead and partner). However this
breaks on any model not having those two fields and inheriting from the
'mail.thread.phone' mixin.
In this commit we use the result of ``_phone_get_number_fields`` to know which
fields to use in the SQL query.
Tests are added to ensure it works as intended.
Task-3012789
X-original-commit: 6b235868da6fed1b2a0eaa7a25dc2202c6fefaa0
Part-of: odoo/odoo#104111
In order to better reflect real models, let us have phone and mobile fields
being computed either by hand, either based on customer on 'mail.test.sms.bl'
test model.
Done in its own commit to ease discovering of side effects in tests, which
does not seem to be the case.
Task-3012789
X-original-commit: 71e2b8713bc83ed999ab2e2839edc56804a0fe54
Part-of: odoo/odoo#104111
Before this commit, when a Project user opens the "Burndown Chart"
report from Project app, a traceback is occured due to an invalid
domain in the `ir.rule` for this report.
This commit fixes the issue by updating the domain since the `task_id`
field no longer exists on that report.
task-2982150
closesodoo/odoo#104107
X-original-commit: ce60532b0c5c77a80038298a27550ab5f9eeb012
Signed-off-by: Xavier <xbo@odoo.com>
The initial bug report was the ability to disable all companies
at once and messing up the whole database when you do so.
However, forcing administrators to choose a new company for active users
before archiving a company seems relevant, and solve the
above reported issue in the same time.
closesodoo/odoo#104112
X-original-commit: 786ed3c7a688a662767abfb6e74e7f6dbc938f2e
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit adds the w-100 classname to the div containing
the field used for the name of the task. It was no longer
using all available space.
After this commit, the title takes the full width available.
closesodoo/odoo#104103
X-original-commit: 482a597527a227c45afa4e0d85b0bcdcb8866a5b
Signed-off-by: Xavier <xbo@odoo.com>
This commit adapts the codebase to match its enterprise counterpart
where calls to legacy cookie api (cf. web.utils.cookies) are replaced by
cookie_service ones.
closesodoo/odoo#104080
X-original-commit: 724469e19ff83e91a41c6721e334df1ad8d1c02c
Related: odoo/enterprise#33189
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
As the current test suites are "light mode" based and to avoid
unexpected errors when running them locally (due to the cookie
possibibly being already set), the dark mode is disabled
for the following suites:
- `web.qunit_suite`
- `web.qunit_mobile_suite`
- `web.benchmark_suite`
X-original-commit: 3f1b44f0d2ce72f79308ef36cd72ea3f7b82b186
Part-of: odoo/odoo#104080
Due to the deprecation of t-esc to the unique use
of t-out in the rendering template, this replace
every usage of it and ensures everything continues to
work as inteded. Removing deprecation warnings
polluting terminal
deprecation commit: odoo/odoo:9ce5bc8881ae06b613ef61eb07453b224f62bae6
closesodoo/odoo#103731
Related: odoo/enterprise#33037
Signed-off-by: William André (wan) <wan@odoo.com>
This commit cleans up a bit of the emoji picker modeling, and
removes a bit of dead code
Task-2985893
closesodoo/odoo#103411
Related: odoo/enterprise#33128
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, if an invalid list view is left, then a "View can't
be saved" error dialog is displayed.
The expected behaviour is a notification indicating the invalid fields.
How to reproduce:
- Go to a list view with at least one required field
- Create a new record
- Edit this record while leaving the required field empty
- Leave the view
Before this commit:
You stay on the view and get the "View can't be saved" error dialog.
After this commit:
You stay in the view and you get a notification "Invalid fields: "
with the invalid fields displayed.
closesodoo/odoo#104082
X-original-commit: 98fbacd8511594ca7a8cc9f0afa5d199a9b2ff20
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, in a list view, if you click on a readonly field of
a record in edit mode, then it switches to readonly mode.
Why ?
The "pe-none" class added to readonly fields will prevent clicking on it.
Our click will then be applied to the table causing a unselectRecord
on the list.
How to reproduce:
- Going into an editable list view with a readonly field
- Click on a field to switch the record to edit mode
- Click on the readonly field
Before this commit
The record switches to read mode
After this commit
The record stays in edit mode
closesodoo/odoo#104070
X-original-commit: 52c817b88b5c799322a19f49807126928d9f28e1
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Before this commit, in a multi_edit list view, if you click twice on
a readonly field, the focus is placed on the readonly field.
How to reproduce ?
- Go to a list view in multi_edit="true" mode with a readonly field
- Select a record
- Click on the readonly field of the selected record
- The record goes into edit mode and the focus is placed on the editable
field following the readonly field
- Click a second time on the readonly field of the selected record
Before this commit:
The focus is placed on the readonly field.
After this commit:
The focus is placed on the next editable field.
X-original-commit: aac7e6e4de371dcd01028a3a9ab66eed022c1ef0
Part-of: odoo/odoo#104070
In a kanban arch, have a dropdown that don't have a toggler, just an
explicit menu.
Before this commit, there was a crash.
After this commit, the kanban and the dropdown are correctly rendered.
closesodoo/odoo#104019
X-original-commit: 01418c474cb02455660156cf47822588f0554376
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a kanban arch with a field in display full in the kanban card template
```<field name="fieldName" display="full" />```
Before this commit, the class that should endup in the DOM was wrongly computed.
Technically, it was quoted in the owl template as if we passed it to a Component.
After this commit, a field having display="full" is correctly rendered.
X-original-commit: 526eb4f875ec6736d4b76da1fbdbcc99a8c33a9b
Part-of: odoo/odoo#104019
Before this commit, the usage that KanbanRecord makes of useViewCompiler was faulty in that
it did not respect the hook's API (the last argument is a dict params, not a string).
After this commit, the usage of useViewCompiler by KanbanRecord is correct.
X-original-commit: 8dbf7c88742e4603543005a1d5a158e5e0db2feb
Part-of: odoo/odoo#104019
`__manifest__.py` was introduced in Odoo 10 and quickly migrated
to (c758e9043a fixed the last holdouts).
Deprecate old manifests. People who need the compatibility can just
add a symlink (or duplicate the file if they're working on FAT or an
old os where core.symlinks can't be set to `true`).
closesodoo/odoo#103952
Signed-off-by: Raphael Collet <rco@odoo.com>
Improve the NZ localization by enabling the anglo saxon accounting by
default, and adding a new default stock output account.
task id #2993527closesodoo/odoo#104081
X-original-commit: b1f4b19fa1fd27892430ede363358cf0f17fc796
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
This commit restores the possibility to control the height of the
image gallery snippet. This was indeed possible in <= 11.0 for all
snippets but it was removed in 12.0 as controlling the height via inner
paddings seemed enough and better (as responsive). For the image gallery
snippet however, this was a big regression as the height is forced to
70% of the current screen height on drop and the images inside are
displayed depending on that forced height. Trying to control via
paddings was not leading to the wanted effect.
This restores the possibility in 14.0 as 12.0 and 13.0 are now
deprecated. This is following a customer issue where not having the
ability to control the height is actually confusing as the user edits
its website across different screens and the height is forced to 70%
height of the screen used at the time of edition. With an height input
in the panel, the confusion is gone.
Note: this also introduces a `forceStyle` parameter for the
`selectStyle` option to be able to force the inline style a widget
controls. Indeed, without it, the system is "smart" and tries not to
force inline style when it is not needed (if you try to force red on
something that is naturally red (thanks to a CSS rule for example), it
won't be forced). Here, this was leading to an issue when trying to set
the height:
- Current height is 700px
- There is some code that forces a min-height on all carousel items so
that they are the same height. As the gallery image dimensions depend
on the block forced height (this is how the snippet work), the forced
min-height are related to that forced height (something like 680px).
- You focus the height input and type 800px
- The same code forces new min-height on all carousel item (something
like 780px).
- You un-focus the height input, the system tries to re-set 800px (which
is already set)... it ends up removing it as it thinks that setting
that height is not needed as the snippet is now "naturally" 800px tall
thanks to the carousel items' min-heights.
opw-2838774
closesodoo/odoo#104068
X-original-commit: d4d0da320d42093e720c7d440cf6611249c0295a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The group unification done by https://github.com/odoo/odoo/pull/95729
missed adding the often mandatory `product_uom` into some views when
`uom.group_uom` is False. This is the case for repair and blocks the
user from saving its form view in this case.
X-original-commit: 72dff43a4da277b002966f5fd4045b7f9a3855ad
Part-of: odoo/odoo#104067
Steps to rerpoduce:
- Create a sales order with a subscription that has also materials, we
need that the service product creates a project when a quotation is made
- Inside this project, we go to Project Updates, click on Materials.
Issue:
Materials is throwing an error, so we cannot check the materials in the
project.
Solution:
After the project changes to OWL we need to change the way we pass the
parameters to the 'action_profitability_items', so it matches the new
changes.
opw-3024598
closesodoo/odoo#104069
X-original-commit: 67731daf264fb17dbde1d360ba5e285cd193b446
Signed-off-by: Xavier <xbo@odoo.com>
The company is very often used in the queries because of the record
rules (i.e. `account.account_move_comp_rule`).
Adding the index can help improve queries coming from multiple places.
closesodoo/odoo#104066
X-original-commit: b2f620c59861e76443364f5bab6cade7c8eeca93
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Before this commit:
When trying to edit a link with mailto, there is an "https://"
added and preventing the link to work successfully
After this commit:
The mailto part of the link is correctly kept as is and the link works.
Task-2961012
Task-2977682
closesodoo/odoo#104064
X-original-commit: a22d6d1859a8f97c3cccdba755392cd13d7eb866
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
when you open course ratings view, it may show also
some project ratings, if project id is same as course id.
This commit solves the mentioned problem.
Task-2997847
closesodoo/odoo#104057
X-original-commit: 73be65459550470f9839fb4f7c4bb2db65cb37ec
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Prior to this commit, the table border color was only applied to the
columns (left and right borders).
This commit applies the border color to all borders and adapt the color
to be consistent with the dark mode.
task-2710677
closesodoo/odoo#103162
X-original-commit: fc8a0653c2e98cbda9c1ff60f3a5ea7347aadd48
Related: odoo/enterprise#32786
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit adapts the color of `MessagingMenuTab` for dark mode.
task-2710677
X-original-commit: 2b641f3140b784c2f4c03fd3a76c8fda2e0ed79e
Part-of: odoo/odoo#103162
This commit adapts the colors of section rows for dark mode.
task-2710677
X-original-commit: 9302f920b3d6f31bc2cf24a7ac47a49343cca7c4
Part-of: odoo/odoo#103162
This commit adapts the `o_VisitorBanner` background for dark mode
task-2710677
X-original-commit: f3c6f50ed17d7fdf3f1286830d5feeb6bc9b0b57
Part-of: odoo/odoo#103162
Since the introduction of dark mode, Odoobot's avatar must have a white
background, otherwise it's not visible enough.
This commit fixes this issue.
task-2710677
X-original-commit: 36707e4cf64db231ed796c0244a62309e8eee529
Part-of: odoo/odoo#103162
This commit adapts color of `survey_question_views` for the dark mode.
task-2710677
X-original-commit: 08b3e78fab239f914301e8d67e0a1f1bf91bf5bb
Part-of: odoo/odoo#103162
This commit adapts the color of icons in the Time Off Type section for
the dark mode.
task-2710677
X-original-commit: a5f108c5b9ea1008e2c5b519902bbf6398b02233
Part-of: odoo/odoo#103162
The delivery slip of a receipt picking with a vendor uses the vendor
details as the delivery address
Steps to reproduce:
1. Install Inventory
2. Go to Inventory > Operations > Transfers and create a new transfer
with:
- Contact: Azure Interior
- Operation Type: San Francisco: Receipts
- Product: Large Cabinet
3. Save the transfer and print the Delivery Slip
4. The delivery address is wrong: it is the partner's address
Solution:
Change the conditions used to print the delivery address and the
warehouse address to print the warehouse address when the delivery
address is the same as the partner address
opw-2992693
closesodoo/odoo#104051
X-original-commit: 99d04c20896dd06b4d083fe6c079a90e840e3ca2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Joseph Caburnay