On my system in chrome 92 there are issues of chrome's hitboxes (and
rounding) being off leading to tests failures, something which given
the adjustment in `triggerMouseEvent` had been an issue in the past.
The first test failure was / is in the "correctly display year view"
calendar test, where the very first event dialog would fail to open
when clicking on the `2016-11-16`.
After tracing through fullcalendar, it turned out fullcalendar was
told to hit `2016-11-*09*`, suspiciously 7 days before the cell we
were looking for in a monthly calendar, hinting to an incorrect
vertical offset / hitbox.
Fix by offsetting the top coordinate in `triggerMouseEvent`, but
rather than just increment by one update the entire thing by trigger
the event right in the middle of the element being targeted, that
seems more reliable long-term, though it could be slightly confusing
for events like mouseenter/mouseover/...
The second issue was with a list test, where two cells are supposed to
be sized equally. Apparently the offset sizes are supposed to be the
rounded version of the actual size (which can be fractional), but
dumping the information of `foo` and `text` I'd get real widths (via
getBoundingClientRect) of respectively 480.46875 and 480.5, and
offsetWidths of 481 and 480 (the smaller of the two in "real size"
is rounded higher than the other one).
In Python we might use `assertAlmostEqual` for this, but we've
apparently not introduced this in JS take the real width and round up
by hand, this fixes the issue as both end up at 481.
Aside 1:
Before finding out the actual root cause I landed in
`_onYearDateClick` with missing data in the events so looked at the
API to figure what I was looking at, and turns out fullcalendar's
event object has documented properties to get the date-converted start
and end bounds of the event, so use that directly instead of doing the
same thing by hand.
Aside 2:
The attributes passed to `triggerEvent` in `triggerMouseEvent` are
pretty much nonsensical, we're getting the element's location using
`getBoundingClientRect` which is based off of the viewport, but
setting the keys
* `screen(X|Y)`, which should be the location of the hit relative to
*the physical screen*
* `page(X|Y)`, which should be the location of the hit relative to the
page / document (so takes in account the content scrolled off-screen)
* `layer(X|Y)`, which is the position of the hit relative to the
nearest positioned (non-static) element, falling back to page if
there isn't one
The one attribute which matches the semantics / reference of
`getBoundingClientRect` we didn't even set, instead it would be
automatically copied from `pageX`/`pageY` by the events mapping.
Fix that by just providing `clientX`/`clientY` and updating the
mapping functions to not overwrite it.
If the others are needed they should be computed properly based on the
document's bounding client rect and scroll information, as well as the
window's screenX/screenY (and offsetParent for layerX/layerY though
that seems unlikely to be necessary).
closesodoo/odoo#75953
X-original-commit: d26a4edffd6bdaed46143a30e99f17eb91f44e7e
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Since we change the editor for the comments on invoices,
The layout was a bit broken with some unwanted spacings.
task-2586137
Part-of: odoo/odoo#75863
The service is called `notifications` when mocked in tests,
instead of `notification`
closesodoo/odoo#75859
Related: odoo/enterprise#20554
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
In the spreadsheet app, we need the exact same values which are saved
for "ir.filter" records.
This commit refactor a bit things to allows getting those values without
actually creating the "ir.filter" record.
Task 2572184
Part-of: odoo/odoo#75859
Co-authored-by: LucasLefevre <lul@odoo.com>
Purpose
=======
Time Off : New Dashboard, Accruals feature, Public holidays, New time off type configuration view.
- Review of Dashboard
- Accrual feature : Currently, when you create an allocation, it's possible to create an
Accrual, but there is no appraisal Plan. An Appraisal plan is use to define steps of accruals
for each employee.
In Belgium, we use accrual Allocation for European Leaves, or compensatory hours, it's a
simple use case. But in USA, it's possible to change the calculation mode each year.
Also, in USA, it's possible to deal your accrual plan when you arrive on the company. It's a
HR Officer task to create the right Accrual allocation for each new employee.
- Public Holidays :
Improvement of global time off feature located on Working hours calendar. Now, Time off
application have to manage Public Holidays.
- Review of Time Off type configuration
COM PR: https://github.com/odoo/odoo/pull/72511
ENT PR: https://github.com/odoo/enterprise/pull/19157
UPG PR: https://github.com/odoo/upgrade/pull/2791
TaskID:2475413
closesodoo/odoo#72511
Related: odoo/enterprise#19157
Related: odoo/upgrade#2791
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: William Braeckman <wbr@odoo.com>
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Before this commit, when loading a view containing a searchbar on a
tablet, the device's keyboard is appearing once the searchbar's field is
autofocused.
Thanks to the backport of the mobile OS detection (see PR
odoo/odoo#75455 ), we are now able to properly target mobile OS
(independent of the screen's resolution) instead of only small screens.
closesodoo/odoo#75880
X-original-commit: b1a7296f060811153039ef73140e78ea702088a1
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
During the refactor of the comparison feature, the pie_chart widget was forgotten
(commit: be5a51a345)
Before this commit, the pie_chart widget did not support timeRanges any longer
After this commit it does again.
closesodoo/odoo#75878
X-original-commit: 4f64cd724ad2a58a35dadf382b10dab74e1c0559
Related: odoo/enterprise#20564
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Change the command palette shrotcut from CTRL+K to CTRL+M,
in order to avoid conflict with link creation shortcut in editor.
task-2635043
closesodoo/odoo#75828
Signed-off-by: Bruno Boi <brboi@users.noreply.github.com>
* = crm_livechat, hr, hr_holidays, im_livechat, mail_bot, purchase, sms,
snailmail, survey, test_discuss_full, test_mail, web_editor, website,
website_livechat
- Create new model `mail.guest` for guests.
- Rewrite some RPCs to target routes rather than model methods so that
guests are able to use them.
- Patch JS and python models to support guests.
- Create a stand-alone page and boot the channel in it.
task-2494829
closesodoo/odoo#75496
Related: odoo/enterprise#20417
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, every view had to have its own rules to avoid
breaking the control panel when there was an horizontal scroll.
a) We now always use 'overflow-x: auto' to be able to scroll the content
of the view if there is not enough space available.
However, we doesn't want double vertical scroll; one for the page and
another one for the content. It's why we added visible to the previous rule:
"overflow-x: auto visible".
b) overflow: visible; is the default value. We simply deleted this line.
c) We need to set height: 100%; to allow the pivot view to grow when a
dropdown pops out. Otherwise, it will be cutted.
Steps to reproduce:
* Go to Sale
* Select the 'Pivot' view
* Add 'Customer' to group horizontally
* Scroll to the right => BUG
Task ID: 2232265
closesodoo/odoo#75826
Related: odoo/enterprise#18121
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Following commit 118ddcace0.
a few console.log escaped the attention of the reviewer.
This commit removes them.
closesodoo/odoo#75832
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit enables the zoom on mobile.
To avoid any issue in website, we first only activate it in the backend.
Note that it's not, strictly speaking, a zoom. It only shows the
original size of the picture.
Steps to reproduce:
* Open Employee
* Select an employee
* Touch on the photos
closesodoo/odoo#75785
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
ISSUE ADDRESSED
- Open Project > Tasks > Gantt view
- Click the ADD button to open the form dialog
- Fill the form and click on SAVE&NEW button
- Fill again the form and click on SAVE&CLOSE button
- Both tasks are created, but only the first has been planned, because the second one has lost a part of the context (plan dates...)
BEFORE
Opening a form view dialog without passing a _createContext method (see commit c14b17c485 where it was introduced) was still passing an empty object additionalContext argument when save&new was hit.
This was leading to not take into account the full context (see BasicModel._getContext).
AFTER
If no _createContext method is passed to a form view dialog, then no empty object additionalContext is passed to evaluate the context, resulting in the full context being used.
closesodoo/odoo#75807
X-original-commit: 3fe5961988220b2864db005ae9d79474de608fc5
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
Signed-off-by: Bruno Boi <brboi@users.noreply.github.com>
Adapt css to allow a nice display of ribbon widget on kanban.
Task-2634805
PR odoo/odoo#72298
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Mariska Archielli <ram@odoo.com>
The kanban view allows to instantiate widgets but not to give attributes as
options. Fine tuning some widgets require to be able to control them directly
from XML declaration using options and attributes.
Task-2634805
PR odoo/odoo#72298
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Mariska Archielli <ram@odoo.com>
Before this commit, the sync buttons refactored in https://github.com/odoo/odoo/pull/68700 would appears in all calendar views (sale,time-off,...).
This commit only displays them in the calendar event view.
closesodoo/odoo#75702
Taskid: 2633415
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
*: web, website
This commit redesigns the editor toolbar improving its visual appearance
and introducing substantial changes wherever it is rendered.
== "Into-sidebar" design
The grid layout has been refined, improving its components allocation.
For the sake of visual simplification, "list-type" buttons have been
unwrapped from their original dropdown. For the same reason the button
to create a new table has been removed (users will have to use the
command-bar to create a new table).
Table's options have been moved to a section "ad-hoc", visible only when
a table is selected.
== Floating design (backend only)
The toolbar is now white to match the command-bar design.
In order to simplify frontend inheritance, the floating toolbar now uses
grid layout.
== Colorpicker
The generic code necessary for each design has been moved from
'wysiwyg_snippets.scss' to 'wysiwyg.scss'.
The style is now controlled by css variables allowing to customize
critical design properties without the need of SCSS overrides.
By default the design is white(-ish) to match the floating toolbar,
while in 'wysiwyg_snippets.scss' the variables are customized to get the
typical sidebar's dark feel.
Note: despite the task main objective was just to improve/fix the
design, this aimed to simplify design inheritance and reduce the css
too. While inheritance has been improved reducing the amount of
overrides, the attempt to reduce the css partially failed (in the final
lines count must be considered that a new sidebar section has been
created).
The reason is that we currently suffer from a deep and complicated
inheritance structure for this component. The xml template uses default
bootstrap classes that are styled differently depending if loaded in a
community or enterprise environment. This approach leads to overrides
that must cover all the scenarios while further customization must be
taken in account too 'cause the toolbar can be rendered into the sidebar
with a totally different design.
A possible solution would be to detach from bootstrap directly in the
lib using custom classes names, and then @extend these classes
differently according to the current environment but probably not a good
idea as we want the toolbar to use bootstrap for in-website editors (so
they can match the theme correctly) but this has to be reviewed as well
anyway. To be checked.
Part of https://github.com/odoo/odoo/pull/73565
task-2496339
closesodoo/odoo#73565
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
This commit is part of the 2 factor authentication revamp.
The purpose is to avoid to display error modals when it's possible to only
display a notification toaser.
Task-2487630
Part-of: odoo/odoo#71142
Purpose
=======
Review the UX of the 2-factor authentication flow in order to make it more clear
and easy to use.
Specifications
==============
This commit applies multiple rewording of instructions, button, etc. Tests have
been adapted accordingly.
It also adds an 'invite to use two-factor authentication' flow that will
send an email to the selected used to redirect them their account security
settings.
- If portal is not installed yet, the user is redirected to his account security
settings in backend.
- If portal is installed, the user is redirected to /my/profile if them are
portal user. Otherwise, the redirection is still done at backend side.
As the backend view of auth_totp wizard is used at frontend side, copyclipboard
widget has to be rebuilt at frontend side (click event, style etc..).
As API key section is now displayed only on debug mode, test urls have been
adapted accordingly.
Task-2487630
Part-of: odoo/odoo#71142
Adds the possibility to search an app/menu from the command palette .
It allows for fuzzy-searching apps and their submenus as shortcuts to directly
enter the right app and submenu and execute the corresponding action.
The comamnd is initiated by typing "/" in the command palette.
closesodoo/odoo#75396
Task-id: 2622952
Related: odoo/enterprise#20447
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit adds the smarts actions:
- Assign to... (many2one_avatar and many2many_avatar)
- Assign/unassign to me (many2one_avatar and many2many_avatar)
- Set priority... (priority)
- Set kanban state... (state_selection)
These smarts actions are commands with hotkeys accessible from
the form views containing the widget to which they are linked.
closesodoo/odoo#75312
Task-id: 2588238
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Two tests in owl_dialog_tests were not correctly added in the parent
module of owl_dialog_tests.
These orphaned tests will therefore be associated with the previous
Qunit.module("name") and it will use its beforeEach.
If the module used does a makeTestEnv in its beforeEach, then the
"remove tabindex on inactive dialog" test will cause
"Error: Cannot add 'xxx' in this registry: it already exists" errors
because the test call createWebClient that does a second makeTestEnv.
closesodoo/odoo#75696
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
PURPOSE
Allow to group records by many2many fields.
Use case: turn the user_id m2o field on project.task into a user_ids m2m field
in order to assign multiple collaborators on a task
SPECIFICATION
Add many2many fields to the 'list of groupable fields'.
When grouping a set of records by a many2many, records linked to multiple
records of the comodel will essentially be in multiple 'groups' (even though
those are not really 'groups' anymore).
There will also be a "null" group, for records that have an empty value of the
many2many, like "unassigned" records.
Example: grouping a project.task linked to 10 res.users by the user_ids
many2many field, the project.task will be 'rendered/considered/displayed' 10
times, once per res.users.
Kind of like if we grouped the m2m relation table instead.
When grouping by a m2m field:
- listview
editing an instance of a record also updates each other instance(if any)
- the same goes when scheduling an activity, etc.
disable deletion
- the risk here is that the user might expected that this will 'unlike'
the record from a specific record of the many2many field
disable archive/unarchive
- kanban
disable drag&drop between groups
disable deletion
disable archive/unarchive
- searchview
display many2many fields custom groupby dropdown
With this commit, we also support groupby many2many field in mockServer so that
test cases are written based on that.
task-2508608
closesodoo/odoo#74985
Related: odoo/enterprise#20192
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The value returned by the search_read in read_progress_bar when passing
a m2m field is a list of ids, which then read_progress_bar tries to use
in a dictionary, list is not a hashable type thus it crashes.
With this commit we convert the group_by_value from list to tuple,
which is hashable, if we're dealing with a many2many field.
task-2508608
Part-of: odoo/odoo#74985
Purpose:
=======
This commit adds the project sharing feature. This feature consists to
share the backend views about project.task to portal users.
About the access rights:
- The project manager can share a project with project sharing feature.
To do this, he need to give access to portal users that we want their access in project sharing views.
He can choose between 2 differents accesses:
1. **Readonly**: The use has access to the classic portal views (on which he can post messages, and have a readonly access rights to the related fields)
2. **Edit**: the portal with this access right will can edit some fields of `project.task` model.
The difference between the classic backend views and the project sharing
views is in the project sharing views, we list the fields that the user
can read/write, so the portal users can see only the fields in
our list.
Moreover, the actions and the contextual menu (actions dropdown) are not
available in the project sharing views and the stat buttons are visible
but the click on these buttons are disabled.
Implementation details:
======================
- add `allow_project_sharing` option in project form view.
- create the webclient and routes.
- create own qweb bundle.
- add project sharing views.
- use the session to define the action and active_id
- create public fields for project sharing: in this step, we lists all field
names of the `project.task` model that we want to display for the
portal user. Two lists are created, one for only readable field names
and the other one for the writable field names.
Moreover, two properties are defined in the `project.task` model to use the
both lists.
- use `access_token` and check model in project sharing route: in this
step we check if the model is `project.project` and the `access_token`
is the one set in the project since we have the id of the project in the
params url.
- protect ORM methods: to avoid the portal user has accessed to too much
fields that he can, we have to check if all asked fields are in
the readable fields, if all fields are available for these users than we do the
method, otherwise we raise an `AccessError` exception.
- allow only `GET` method to enter project_sharing routes: the
`/my/project/<int:project_id>/project_sharing` route must only be
called with a `GET` method because this route is only used to have the template
to render the project sharing webclient.
- redirect the link in one of the sharing wizards to project sharing views if the portal user has an access
to the shared project and if the shared project has the Project Sharing feature enabled.
- only load `project.task` views for project sharing.
- remove longpolling in the project sharing.
- disable click on avatar to open the chat with the user or open the hr.employee form because these features are not authorize in the project sharing.
- remove the contextual action menu in the project sharing views
- add the chatter in the `project.task` form for the portal user with at least 'comment' access.
This user could send message and see the public message like portal chatter.
- replace the basic portal views when the portal user selects project in `/my/projects` by the project sharing views if the `allow_project_sharing` is enabled for this project and if the portal user can access to the project sharing views of this project.
Why did we implement this feature in this way ?
====================================
We thought to create a `project.task.portal` model. This model had contained all fields that the portal user can read and edit (`readonly=True` if the portal user can just read the field).
We had 2 possibilities for this solution:
1. link this model with `project.task` either with inherits attribute in `project.task` or by creating a many2one field in the project.task.
The problem with this solution is with `inherits`, we just copy all fields in `project.task` and not method, so we need to duplicate methods used in both models. Moreover, with `inherits` possbility, we have to create all records even if the Project Sharing feature is not used. If we took the other possibility (that is, create the Many2one field in `project.task` model) asks to create records when the `allow_project_sharing=True` in a project and also unlink/archive records when the Project Sharing feature is disabled in a project. The process is harder each time, the user enables/disables the feature. That's why we didn't do this solution.
2. the new model contains a sql view and we use the related field to create/edit tasks in project sharing views.
We don't do this solution because it was a big change and increase the complexity. Moreover, if the sql view gives all tasks of shared projects, we could have a security issue because the portal user could have access to the tasks of shared project in which he didn't have any access.
Another solution that we thought before doing this feature was to create the kanban view in portal. We didn't do that because:
1. the render of this view will not be the same than the one in `/web`,
2. we didn't want to duplicate the kanban view,
3. we need to allow the portal to create/edit task.
task-2379518
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#73341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Rename `Debug Menu` => `Debug tools...`
Remove `Debug tools...` hotkey
The commands in the debug category need to have a search value
to be displayed.
Task-id: 2622240
Part-of: odoo/odoo#74933
This commit is a refactoring of the command palette. It aims to improve
its design and make it very easily configurable. For this, we added the
config props allowing the command palette to know what to display.
The config of a palette command is composed of:
- categoriesByNamespace?: list containing all categories according
to their namespace;
- emptyMessageByNamespace?: dictionary having for key a namespace and
for value the message to display if there is no choice available;
- footerTemplate?: template to display in the footer;
- namespace?: namespace to add in the search bar;
- placeholder?: placeholder of the searcher;
- providers: list containing all the providers generating the commands
to display;
The providers are the only information needed in the config. The rest of
the config is optional.
This commit also adds the possibility to open a custom command palette
using the command service. For this, you just have to call openPalette
and give it the required config.
If the command action returns a config, the command palette will
not be close and will use this new config.
Task-id: 2622240
Part-of: odoo/odoo#74933
Before this commit, when we set `no_open` in list view for x2m record in
form view, the no_open is not take into account. Either the list is
editable and then the form dialog is no displayed and the user can edit
in the list or the list view is readonly and when the user clicks on a
row in this list view, the form view dialog appears.
This commit changes the condition in the `no_open` to force to set to true
when the no_open is set to true. So, when the no_open=True even if the
list view of x2m record is in readonly, the form view dialog is not
called and thus it will no longer appear in this case.
task-2379518
closes#73341
Regarding previous commit, the option parameter can be removed
from _get_asset_content api, followed by a nice snowball effect.
Part-of: odoo/odoo#75248
Before this commit, the calendar UX was not good enough. The look and feel was not modern.
This commit improves a lot of small details, remove unneeded or not mature features (like the videocall location url).
Counted recurrence now brings a better experience. When weekly or montly recurrences are created, occurences in the past are dismissed but before this commit their number was not adapted.
User would end up with less occurences than the provided number without explanations.
Taskid: 2484335
Part-of: odoo/odoo#68700
Before this commit, the calendar filter was a little bit limited: you could add filters to only display events related to these filtered records or display all events.
If you wanted to select all active filters, we had to check all these individual filter.
This commit introduce the possibility to select all existing filter at once or to unselect them. It is quite convenient when a lot of filter are displayed but unchecked.
Taskid: 2484335
Part-of: odoo/odoo#68700
Before this commit, it was not possible to reapply all events in recurrence, delete all events of a recurrence or archive them.
This commit remove that limitation by reapplying the recurrence and remove all the existing events. When the events are synched, the action_mass_archive is used and it must ensure that only a request for the recurrency should be sent.
Individual request for each event are not sent.
Taskid: 2484335
Part-of: odoo/odoo#68700
Before this commit the browser did freeze if scrollTo(undefined) was
called. This happened because our "closestScrollable"'s jQuery addition
entered an infinite recursive exploration of .parent() elements starting
from $(undefined).
After this commit such wrong calls to scrollTo() will not freeze the
browser anymore but crash instead. The closestScrollable function was
also made more robust and return an empty element instead of looping.
task-2630257
X-original-commit: d1cda0f3ebb942ad58273db36692f28fa8a3b197
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit backports the mobile OS detection support, and specifically
Android & iOS one to allow more specific targeting of edge cases (i.e.
disabling native date picker in the mobile iOS app only).
opw-2613810
closesodoo/odoo#75577
X-original-commit: 7015dcd56566e93418f51e8e3562f384d10b4ffa
Related: odoo/enterprise#20446
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Improves overall signature wizard usage. Signature will adjust its size to best
fit the canvas, but maintaining its ratio.
task-2596079
closesodoo/odoo#73493
Related: odoo/enterprise#19577
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
On 00e3cb74c4 the migration of the code to
parse and formate dates on the mock server from moment to luxon was
done. Two issues were introduced on that commit: Parsing a date
displayed on quarter wasn't possible; And the ISO week year wasn't used
to format the date, but it was used to parse the date, for symmetry's
sake, now the ISO week year is used on both.
closesodoo/odoo#75354
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
The algorithm extracting primary and secondary colors from
an image automatically mitigates too bright colors. A color
component is considered as too bright if its value is above
an arbitrary value. We re-use this algorithm in the website
configurator to extract colors from logo and to generate a
palette. In this particular case we don't want the mitigation
to be applied. We therefore added the mitigation threshold as
a parameter of 'extract_image_primary_secondary_colors' and
avoided any mitigation by setting it to 255 in our case.
task-2602521
closesodoo/odoo#75255
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
*: web
After this commit pre-configured gradients can be used as snippet
backgrounds, snippet filters or as text effects / highlight effects.
The background colors (and now gradients) are now possible to add
*alongside* a color combination class (editing one does not remove the
other). Background colors and gradients are mutually exclusive.
Part of https://github.com/odoo/odoo/pull/73611
task-2599770
closesodoo/odoo#73611
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
In new version of chrome (92) or firefox when some fonts (eg. courier)
were used:
- either the page would never finish loading (odoo 13 and below)
- or the text would in this font would not be shown (odoo 14 and over)
This was solved in pdf.js whith this commit:
https://github.com/mozilla/pdf.js/commit/8805614a03
And this PR is backporting that commit in 12.0 version up to master.
opw-2621405 opw-2613412 opw-2620186 opw-2618225 opw-2616690 opw-2615502
opw-2616249 opw-2615144 opw-2613969 opw-2613793 opw-2618129 opw-2617736
opw-2622506 opw-2614508 opw-2620883 opw-2622105 opw-2620863 opw-2615326
opw-2622842 opw-2620220 opw-2622842 opw-2620220 opw-2615346 opw-2615026
opw-2618389 opw-2619382 opw-2613286 opw-2621730 opw-2613412 opw-2622029
opw-2620625 opw-2622311
closes#75020closesodoo/odoo#75057
X-original-commit: d3feb26c8923cfde60894058f06dc2c2a8be05f5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
We introduce here an incomplete implementation of the new ControlPanel.
The idea is to allow the rewritting of the client actions that do not
use the search view but only the breadcrumbs or the button zone...
The full implementation of the new ControlPanel will be merged when the
new search infrastructure is ready to be merged.
closesodoo/odoo#75083
Related: odoo/enterprise#20231
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
- fields/format.js has been renamed into fields/formatters.js
- fields/parsers.js has been introduced
- parsers and formatters from l10n/numbers have been moved to
fields/parsers.js and fields/formatters.js
- same for parseCurrency and formatCurrency, and they have been
renamed into parse/formatMonetary
- humanReadable option is now a boolean, no longer a function
- formatPercentage implementation has been simplified thanks to
that reorganization
- tests have been reorganized accordingly
Reintroduces a registry "formatters" that contains util functions for
formatting field values. Those formatters take the same parameters:
value, field, options.
We move some util functions from the legacy file math_utils.js to the
file arrays.js. Those funcions will be used in the new implementation of
the pivot view.
Xavier Morel