The Actions/Print dropdowns may overflow the screen in case of very long
lists of menu entries, when based solely on the default BS4 styles for
`dropdown-menu`.
The `o_dropdown_menu` class forces a vertical limit and a scrollbar when
this happens, and should be applied to those control-panel dropdowns to
prevent this UI glitch.
See also 1c1c0897e8 which adapted
dropdowns to BS4.
closesodoo/odoo#31251
1) Remove the total record tooltip from kanban group.
2) Remove progressbar help from kanban view.
3) Improvements in testcase since we have removed total record tooltip.
When evaluating js tests using the browser_js method, they are
considered a success when 'ok' is found in the console log and a failure
if 'error' is found instead.
This is not very robust and recently failed with this commit : 7410de111f
It adds a filter named 'Error' in a view, when the 'click_all' test
clicks on this filter, a message with the name of the filter is written
in the console, wrongly leading to a test failure.
With this commit, the browser_js method expects a log message in the
browser console with the explicit text "test successful".
On the other hand, any error in the console log will lead to a test
failure but a test can be forced to fail with the explicit error message
in the browser console "test failed".
As a bonus, the python logger should now also log browser js trace messages.
closesodoo/odoo#31158
Let's assume a form view with a clickable statusbar, in readonly.
When the user clicks on a status, the change is saved directly.
When the save fails (e.g. access rights), the statusbar widget
is in an inconsistent state and must be reloaded.
This rev. reloads the whole record and re-render the form when
this happens.
Related to Issue: #1915391closes#29519
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Active currencies are given in session_info, in the page source.
When the user activated a new currency, he had to reload the page
to make the browser aware of that new currency (without reloading,
there was no currency symbol displayed next to the amounts).
This rev. forces a reload of the currencies each time a currency is
edited.
Task #1838654closesodoo/odoo#31192
This commit will add tests for the PR #30656 which added the following commit:
7daa85dd12
The tests in the current commit achieve 100% code coverage for:
- the `image.mixin`
- the overridden `image.mixin` methods in `product.product`
- the `_get_images` methods of ecommerce
- the size logic in method `content_image` (route `/web/image`)
PR: #31181
Issue: wysiwyg asset slow down the loading of the website, error
inadvertently introduced: https://github.com/odoo/odoo/pull/29775
The assets are now loaded assynchroneously, when the editor is needed,
its assets will be loaded.
closesodoo/odoo#30700
Add support for a 256*256 image, to be used in the following commit.
Define sizes in named variables instead of being hard-coded in several places in
the code.
Allow parameters `preserve_aspect_ratio` and `upper_limit` to be passed from
the different helper methods.
Factorize the code inside `image_resize_images` to make it easier to read.
Add new function to compute whether the size of an image is above a given size.
task-34045
PR: #30656
With this option we can define which field is going to be displayed by the qweb
image widget, while logic is still applied to the original field.
For example, we want to show a thumbnail image but when user updates it with the
web editor, we want to update the actual field instead of the thumbnail field.
This is similar to the preview_image of the JS image widget.
task-34045
PR: #30656
[IMP] hr_*: introduce the employee profile
================================
## General Purpose
We want an 'Employee profile' gathering every data about an employee.
The main form view is modified to become this employee profile.
A user can also see his own profile through the Preferences menu.
The new profile replaces the current Preferences view if the `hr` module is installed and the current user is linked to an employee. The Profile will show the employee of the current company.
A user should be able to see and edit his own profile.
*Problem*:
Many fields on hr.employee are protected by `groups="hr.group_hr_user"`.
Therefore, a regular user cannot see or edit those fields.
This protection must be bypassed to allow read/write access to the regular user's own data.
A similar mechanism already exists for `res.users` (for Preferences)
The better (least worst) solution found is to reuse this mechanism by adding related fields on `res.users`.
Pros:
- Don't change security access on hr.employee
- Don't implement yet another custom security layer, risking to add new security breaches
- A lot of fields are added by other modules on hr.employee.
It would have required to integrate them with the custom security layer.
- Fields added by other modules on the user's preferences view (normal view, not the profile)
are automatically included in the employee's profile view.
- Allow the hr.employee form view to be different than the user profile accessible
through the Preferences menu.
E.g. add custom buttons only relevant to the logged in user such as "Request a leave".
Cons:
- Each field from hr.employee that you want to appear on its profile
must be added as a related field on res.users
- Those related fields must be added to user's preferences view (duplicate views)
- They also must be added to `SELF_[READABLE | WRITABLE]_FIELDS`
Note:
When the front-end loads the views it gets the list of available fields for the user (according to its access rights). Later, when the front-end wants to populate the view with data, it only asks to read those available fields. However, in this case, we want the user to be able to read/write its own data, even if they are protected by groups (groups are kept on the related fields on res.users). The front-end need to be made aware of those fields by sending all field definitions.
## Changed modules
### hr_attendance
Adds a stat button to this employee profile showing the number of hours worked last month.
Remove the Boolean computed field `manual_attendance`.
This field is just a shortcut to add/remove the employee's user in the "Manual Attendance" group.
The checkbox is confusing on the employee's form and this should be done through the normal group management screens.
### hr_presence
Display the presence status on the employee kanban template.
The status is a colored chip which can be green (present), orange (to define) or red (absent).
Currently, the presence status is only computed when accessing the report view. As this commits displays it on the employee kanban, it should be updated more frequently.
The state should not be updated every time the kanban view is loaded since the computation is a bit heavy. Instead: add a cron to update status every hour.
-> The status is accurate on the report view (status is still updated
when loading the view)
-> The status in accurate at 1 hour on the kanban view
### [ADD] hr_attendance_presence
Bridge module between `hr_attendance` and `hr_presence`.
This PR integrates `hr_presence` module in the employee profile and adds the presence status on the employee kanban view. But `hr_attendance` adds at the same place a similar status icon for checkin/checkout.
This bridge module makes the status from `hr_presence` invisible as `hr_attendance` should be the main presence control mechanism.
Also, this commit adds the ability (through a new setting option) for `hr_presence` to take into account checkin/checkout to determine the presence status.
### l10n_be_hr_payroll
integration with employee profile
[ADD] hr_skills: Introduce a new module for employee resumé and skills
=======================================================
Purpose
-----------
Consultancy companies need resumé and skills of their consultants.
For big projects, they often need to send them to their customers.
These information are also useful to statistics.
Specification
-----------------
### New models
#### `hr.resume.line.type`
Types of resumé lines. e.g. *Experience*, *Education*, *Hobbies*
#### `hr.resume.line`
It is a line in the resumé of an employee.
#### `hr.skill`
Name of a skill. e.g *French*, *Python*, *Piano*
#### `hr.skill.type`
Skills can belongs to a particular type. A skill type has skill levels associated.
e.g. *Languages*, *Dev*, *Music*
#### `hr.skill.level`
Levels available for a particular skill type. Each level has a label
and a progress (between 0 and 100) associated.
e.g. *Intermediary (20%)*, *Advanced (85%)*, *Expert (100%)*
#### `hr.employee.skill`
These are skills which employees have. It links an employee with a particular skill
and level.
e.g. Mitchell has an *Intermediary* level in *Python*
### Access Rights
Only a `hr_user` can create/edit `hr.resume.line.type`, `hr.skill`, `hr.skill.level`, `hr.skill.type`.
If employees are allowed to edit their infos (setting), they can also create/edit `hr.resume.line`,
`hr.employee.skill` for themselves.
### UI
Resumé lines are displayed, grouped by type, in a new 'Resumé' tab in the employee
form. Resumé lines can be reordered (handle widget)
Emloyee skills are displayed in the Resumé tab, grouped by skill type.
[IMP] hr, hr_holidays, hr_expense: Change onchange parent_id behaviour
=========================================================
Purpose
-----------
When the manager (parent_id) of an employee changes, it doesn't always mean that other responsibles (Leave responsible, expense responsible, coach) should also change.
Specification
-----------------
When changing the employee's manager, the leave responsible, the expense responsible and the coach should be changed only if the field was not set or if the responsible is the previous manager. In that case, they should be set to the new manager. Otherwise, it means the field was most probably set manually and it should be left unchanged.
Task 1913089
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#30502
General Purpose
===============
We want an 'Employee profile' gathering every data about an employee.
The main form view is modified to become this employee profile.
A user can also see his own profile through the Preferences menu.
The new profile replaces the current Preferences view if the hr module is installed
and the current user is linked to an employee.
A user should be able to see and edit his own profile.
*Problem*:
Many fields on hr.employee are protected by groups="hr.group_hr_user".
Therefore, a regular user cannot see or edit those fields.
This protection must be bypassed to allow read/write access
to the regular user's own data.
A similar mechanism already exists for res.users (for Preferences)
The better (least worst) solution found is to reuse this mechanism by adding related fields on res.users.
Pros:
- Don't change security access on hr.employee
- Don't implement yet another custom security layer, risking to add new security breaches
- A lot of fields are added by other modules on hr.employee.
It would have required to integrate them with the custom security layer.
- Fields added by other modules on the user's preferences view (normal view, not the profile)
are automatically included in the employee's profile view.
- Allow the hr.employee form view to be different than the user profile accessible
through the Preferences menu.
E.g. add custom buttons only relevant to the logged in user such as "Request a leave".
Cons:
- Each field from hr.employee that you want to appear on its profile
must be added as a related field on res.users
- Those related fields must be added to user's preferences view (duplicate views)
- They also must be added to SELF_[READABLE | WRITABLE]_FIELDS
Note:
When the front-end loads the views it gets the list of available fields
for the user (according to its access rights). Later, when the front-end wants to
populate the view with data, it only asks to read those available fields.
However, in this case, we want the user to be able to read/write its own data,
even if they are protected by groups (groups are kept on the related fields on res.users).
The front-end need to be made aware of those fields by sending all field definitions.
hr_attendance
=============
This commit integrate attendance in the new employee profile.
It also adds a stat button to this employee profile showing
the number of hours worked last month.
Remove the boolean computed field 'manual_attendance'.
This field is just a shortcut to add/remove the employee's user
in the "Manual Attendance" group.
The checkbox is confusing on the employee's form and this should
be done through the normal group management screens.
hr_presence
===========
Display the presence status on the employee kanban template.
The status is a colored chip which can be green (present),
orange (to define) or red (absent).
Currently, the presence status is only computed when accessing
the report view. As this commits displays it on the employee kanban,
it should be updated more frequently.
The state should not be updated every time the kanban view is loaded
since the computation is a bit heavy. Instead: add a cron to update
status every 15 minutes.
-> The status is accurate on the report view (status is still updated
when loading the view)
-> The status in accurate at 15 minutes on the kanban view
[ADD] hr_attendance_presence
============================
Bridge module between hr_attendance and hr_presence.
This commit integrates hr_presence module in the employee
profile and adds the presence status on the employee kanban view.
But hr_attendance adds at the same place a similar status icon for
checkin/checkout.
This bridge module makes the status from hr_presence invisible as
hr_attendance should be the main presence control mechanism.
Also, this commit adds the ability (through a new setting option)
for hr_presence to take into account checkin/checkout to determine
the presence status.
l10n_be_hr_payroll
==================
integration with employee profile
Before this rev., it was possible to specify default values for
categories (fields with attribute select="one") in the context
(e.g. searchpanel_default_fieldname: 5). It is now possible to
specify default values for filters (select="multi") as well
(e.g. searchpanel_default_fieldname: [1,2]).
closesodoo/odoo#31107
On IE11, in 10.0 up to master in some instance when creating a record
under some conditions the dropdown may be automatically opened and need
to be closed.
This has been pinpointed to 90c1af1151 so it seem that a combination of
fields/code/autocomplete and changing the placeholder at one time causes
the issue.
Since IE11 lie and say it is mozilla 11.0 we just apply the 90c1af1151
when the browser is chrome (we did no did this at first to have the same
behavior accross browsers).
note: there is an opened bug in chromium https://crbug.com/928305 if
solved the hack could be removed completely.
opw-1940592
closes#31271
The commit 6d3ada178f
aimed to solve problems occuring whith (single or
double) quotes when creating new custom filters.
Unfortunately, the point was missed and bugs were
still present. The present commit solves the
orginial problem satisfactorily.
There was also a problem in the management of
backslashes. Type '\\' in the search bar would
lead to a domain like
[('...', 'ilike', '\\\\\\\\\\\\\\\\')].
This has also been fixed. Note that it is
necessary to input "\\" if one is looking for a
backslash in db (as before).
A remark on the _formatAST function (py_utils.js):
We deescape only the chars `'`, `"`, and `\`
because it does not seem possible to produce a
string in the search view that would intend a
search for a line return or a tab for example.
A general remark:
Domains should always be in normalized form.
In that way they could be manipulated and combined
together without a tokenization/parsing!
closesodoo/odoo#29756
Before this commit, the wrong semantics was implemented in the webclient
concerning the "sort" char field in ir.filter
Loading a filter with a sort with negative order made the webclient crash
This field holds a JSON string, representing a list of field names
If the order of the field is inverse, there should be a "-" before it
for legacy purposes
After this commit, the semantics have changed for consistency
that is, at save time the sql notation is preferred
We support the legacy notation too for backward compatibility
closesodoo/odoo#31102
Add a new widget for binary fields. It open a dialog box and the user can sign manually,
or an signature can be draw automatically or he can upload a picture of his signature.
Move fonts, controller, scss,templates about signature from portal to web to avoid redundance
closesodoo/odoo#30222
This commit change widget to many2one_barcode in these views:
- sale_order
- purchase
- invoice
- expense
In the fields register 'many2one_barcode' is mapped to many2one as fallback.
many2one_barcode is implemented in odoo enterprise
Task ID: 1924766
closesodoo/odoo#31018
The mobile kanban title tabs required to move from column to column
1-by-1 to go from the first to the last column. Focusing everytime to
only the active column has ugly side effects when the titles are long
(eg. text overlapping).
This commit change the mobile kanban tabs UX by allowing to scroll
through them and go directly from a column A to B. It also improve the
readability independently of the title's length.
This behavior is heavily inspired by Material Design.
See: https://material.io/design/components/tabs.html
Task: 1893168
The goal of this refactoring is mainly to improve the code readability
of the layout update in the mobile kanban renderer by focusing on each
parts separetaly:
* mark current column as the active one.
* compute the title tabs' position.
* compute the content column's position.
Task: 1893168
This commit apply those changes:
- Avoid overflow widgets array by checking its boundaries when the user swipes
on the kanban column.
- Extract the success callback update layout to avoid duplicated code.
Task: 1893168
Sometimes when the groupedBy view is changed the index of the current
active column overflow the kanban tabs length.
In this commit this effect is avoided by resetting the active
kanban column to the first one when the groupedBy is changed.
Task: 1893168
This commit adds the option 'Last 5 Years' in
the list of periods available to selection in
the filter menu and the time range menu for
the date/datetime fields.
Task: 1916017
closesodoo/odoo#29423
This rev. defines a searchPanel widget used in Kanban views to
refine search according to specific dimensions. This wigdet is
displayed as a sidebar to the left of the kanban view.
Part of task 1892462
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
The docstring says they are boolean, but they actually aren't
(e.g. edit="0" in the arch would lead to activeActions.edit=0).
This could cause issue if that value is used to toggle a class
with jQuery, as in this case the flag argument *must* be a boolean.
When embedding the livechat on an external website, we used to make JSONP calls.
As the support of JSONP calls has been dropped, we now use the CORS mechanism
instead.
JSONP can be entirely replaced by the CORS mechanism, which is simpler.
We support CORS in our routes since 8.0 (odoo/odoo@9cce88a), so it's about time
to get rid of JSONP.
Since rev. odoo/odoo@f4d541e the `session_id` cookie uses the `httponly` flag so
it cannot be accessed through client side script. But before this rev. the
`session_id` was still provided by the server to the webclient (in session_info,
mostly) and was stored and accessible. This made XSS injection more
dangerous than they should be as it was very easy to steal the `session_id`.
As the browser automatically set the `session_id` on every request to the server,
the webclient shouldn't need any explicit reference.
- For 'res.config.setting' view, when there is a field with
'many2many_tags' widget, a drop-down is not displayed
properly. (For example, see 'default_cashbox_lines_ids'
field from point_of_sale module)
- This commit fixes the above visual glitch by properly displaying
the field having 'many2many_tags' widget on settings view.
Task id - 1935608
closesodoo/odoo#30956
If that storage is destroy-able (aka RamStorage), storage objects are
created "inline" without attachment (as they may or may not be parented)
and this means those created implicitly in tests can't be tracked and
cleanly destroyed even by destroying the storage service object.
closesodoo/odoo#30790
* portal, web
This commit introduces the first of many-to-come non-color website user
values: the logo height. Now, the user can choose it in the customize
dialog.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
David Monjoie