| Age | Commit message (Collapse) | Author |
|---|
|
from mail to web
with this commit, we have updated the attachment widget view same as like chatter attachment view
moved the common scss code from mail to web for many2many_binary widget, which is used for attachment
and update test case according to the widget
Task ID: 1930087
|
|
This commit improves the usability of ModelFieldSelector widget
with following points:
- add a placeholder on the input for searching fields
- add more height to the same input for consistency
- properly show 'X' sign within header
Task 1916583
|
|
It is now possible to put buttons in the list view group headers.
When the view is grouped by a many2one field, those buttons
appear next to the header title when the group is opened.
The buttons are specified in the views in a <groupby> tag in the
list arch, with the following structure:
<groupby name="groupedField"> <!-- must be a many2one -->
<button type="object" name="my_method" string="Button1"/>
</groupby>
It is also possible to add `field`, inside the `groupby` which can
be used for modifiers. These fields thus belong on the many2one
comodel, like:
<groupby name="partner_id">
<field name="name"/> <!-- name of partner_id -->
<button type="object" name="my_method" string="Button1"
attrs="{'invisible': [('name', '=', 'Georges')]}"/>
</groupby>
These extra fields are fetched in batch when grouping on the field.
Part of task 1915702
|
|
It has been decided to use Chart.js instead of nvd3 to render charts.
In this commit the graph view has been largely rewritten to benefit
from the options offered by Chart.js.
Task ID: 1946138
|
|
|
|
|
|
|
|
Task: 1893104
|
|
Wrong label.
opw-1958313
closes odoo/odoo#32008
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
|
|
|
|
|
|
|
|
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 1c1c0897e8eca607c7f1b96b68a06c026c543e6a which adapted
dropdowns to BS4.
closes odoo/odoo#31251
|
|
[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
closes odoo/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
|
|
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
closes odoo/odoo#30222
|
|
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.
|
|
|
|
closes odoo/odoo#30566
|
|
Before this commit:
Editing a translatable field -> clicking on a translation
warning ->
come back through breadcrumb do not preserve translation
warning.
After this commit:
Editing a translatable field -> clicking on a translation
warning ->
come back through breadcrumb preserves translation warning.
Technical note: alertFields is now an object and an attribute
of the form renderer
that stores translation alerts per record. The translation
alerts
created for a given record are maintained unless
they are closed manually or the renderer is destroyed.
Issue-ID: 1877480
Co-authored-by: Mohammed Shekha <msh@openerp.com>
closes odoo/odoo#29377
|
|
Some aria attributes were missing on menus, and are required to ensure a
good compatibility with keyboard users and screen readers.
To solve the above, the following attributes are included:
- `aria-expanded`: this should be present in all dropdown menus. This is
set on elements with class `dropdown-toggle` and `o_closed_menu`.
- `role`: used to improve given information about what elements are for.
It is added in the following cases:
1. Non-button elements that have the class `dropdown-menu` are set to
`role="button"`.
2. Menu items that have the class `dropdown-item` are set to
`role="menuitem"`.
3. Menu separators that have the class `dropdown-divider` are set to
`role="separator"`.
This is a continuation of baa1c515c592
closes odoo/odoo#29719
|
|
closes odoo/odoo#30045
|
|
This branch introduces a large-scale reorganization of the
component tree generated by the web client. The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:
webClient
/ | \
... ... actionManager
/ \
controlPanel viewController
/ \
to this:
webClient
/ | \
... ... actionManager
|
viewController
/ | \
ControlPanelController
/ \
CPRenderer CPModel
The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons). Also, the action manager had to take care of
coordinating search view states between view transitions.
So, this work simplifies the code. It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code). The changes in this branch should open the way to
implement these features.
For example,
- it will now be easy to add the possibility of views (for example,
the search view or a new ControlPanel view) to add custom buttons
(of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
the presence/absence of sub menus (filters/groupbys/favorites/
time range/...)
- Another need is an easier way for views/client action to customize
their control panel.
This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).
Part of task 1893568
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
|
|
Improve various design elements in sales onboarding and config bar :
Onboarding :
- tooltip and done button
Company info:
- Move the incoterm field from company view to account settings.
Document layout:
- layout widget relabelling and reorganizing
- paper format as required
- added a Preview button
Payment methods and sample quotation :
- Style and relabelling
|
|
With the BS4 update, a traceback occured when clicking on a m2m tag using colors
in a list view.
When using colors on m2m tags, the badge was wrapped inside a `dropdown-toggle`.
However, there is no `dropdown-menu` by default (it is only rendered in FormFieldMany2ManyTags
when clicking on the `.dropdown-toggle`, hence the traceback.
The `dropdown-toggle` class is now only set if necessary.
Task 1925313
closes odoo/odoo#31445
|
|
|
|
Oversight of previous forward-port.
|
|
|
|
|
|
|
|
opw 1889710
|
|
The option `showSearchInput` has been added on the ModelFieldSelector to allow
the user to easily filter the displayed fields. An input is displayed in the
popover title.
The search method is fuzzy for optimal results.
closes odoo/odoo#27788
|
|
|
|
|
|
* requires that current user has group_system
* only visible in debug mode (?debug)
* available at login or via debug menu
* special systray color in superuser sessions
Closes #27254
|
|
- Change icon and design for dashboard subviews buttons, according to
the new mockup.
- Primary buttons are put into the same 'btn-group' to have better
border jointure.
! The new icon for the 'fullscreen button' requires to update
Font Awesome (currently in 4.7 and need at least the 5.0).
Task #1882571
|
|
The navbar in community now looks more like the navbar in enterprise.
Here is a sum-up of the changes in community:
- The navbar in community is now in blue, instead of black.
- No more app list that almost fills the whole navbar: there is
now an "Apps Menu" in the left-most side of the navbar.
- No more sidebar for the menus inside an app: those menus are
now located in the middle part of the navbar.
The navbar in community does not support mobile (< 768px width),
but it should still somewhat usable on most mobile devices.
As for the website navbar, it has been unchanged and should still
support mobile layout.
Task-ID 1878649
|
|
The datepicker lib has been updated to tempus dominus (BS4)
recently, but our code hasn't been adapted correctly to the
requirements of the new version of the lib. As a consequence,
the datepicker didn't close itself when the input was focused
out anymore.
This required a slight change in the DomainSelector widget as it
produced a crash when a focused datepicker widget is removed from
the DOM (before the datepicker is destroyed), e.g. by a call to
html() on one of its parent.
Task 1878254
|
|
Before this commit, it was not possible to open systray menus in mobile.
This is due to popper.js that is wrongly dynamically positioning the
dropdown menu.
This commit fixes the issue by disabling dynamic positioning by popper.js
for the systray menus, so that it uses ou custom styles for dropdown menu.
Closes #26434
|
|
- added two new actions to the form view debug action list,
both opens list (+ form) views of messages and attachments respectively
for which the domain is restricted to the current record.
task: 1860031
|
|
This commit changes two things in the time range menu
appearance:
- the order of range options
- the spacing between them (now two different groups
are separated by an empty lines)
Some tests had to be changed accordingly.
|
|
The search view in mobile mode has been redesigned and looks a bit different
from the search view in desktop mode. This commit adapts the time range menu
appearance in mobile mode.
|
|
Revision on https://github.com/odoo/odoo/commit/017e71322b6b7f0c232f0d66ba659a5972fc3534
Commit above correctly fixes an issue with 'Edit View: X' menu item
in the debug manager, in which the name of the view was missing.
To do so, it lets the controller be aware of the name of the view,
so that it can be used in the template of the debug menu.
However, we think there is a much better solution to fixing this
issue: since the debug manager has knowledge of the view action,
we can extend this object with the name of the view.
This is exactly what this commit does: extend the action view object
so that it knows the name of the view. That way, the template is much
more readable, as `view.displayName` is more meaningful than
`controller.viewName`.
Task-ID 1878254
|
|
Revision on https://github.com/odoo/odoo/commit/f7fbe8adffb1ee585c8171f6c86d38145c11848d
The commit above wrongly assumes that the object 'view' is an instance
of the view class. As a result, the property `display_name` was undefined.
This commit fixes the issue by letting the controller remember the name
of the view in a similar was as the type of the view. That way, the name
of the view can simply be retrieved from the instance of the controller
class.
Task-ID 1878254
|
|
Revision on https://github.com/odoo/odoo/commit/4f6f562c973ce2efd5631ea0e249e75d94cac104
Contrary to what the commit above said, the string was not translatable.
This commit fixes the issue by using the property `display_name`, which
is the translatable equivalent string of `_.str.capitalize(type)`.
|
|
This commit adds a new js test in web that enters each app and click on
each view switcher, each menu and each search filter.
This test is tagged '-standard' and 'click_all' as it could last a long
time, that way it's not executed by default.
It could also be started from the browser console with
'clickEverywhere();'.
|
|
* mail, calendar
- Fix traceback when clicking on a tag without color field (introduced
in recent changes)
- Properly allow to delete tags on firefox (a button obviously cannot
contain another button)
Closes https://github.com/odoo/odoo/pull/26547
Thanks to @hbh-odoo
|
|
Bug revealed with BS4.
|
|
|
