Purpose
=======
Access group terminology is missleading. Yous have to be manager to administrate
an application. This task consists to rename groups to be understandable for everyone.
Groups should be reorganised on the users form to be more explicit.
Specification
=============
1/ Rename 'Manager' to 'Administrator' in users groups.
2/ Define a hierarchy on access groups by using the category_id in the manifests
A category 'Operations/Project' will create a category Project with a parent
category 'Operations', and something smart is already developed (in modules/db.py)
to avoid duplicating categories.
3/ Add a group in expenses to be able to approve expenses reports for my team.
4/ Add a group in timesheets to be able to approve timesheets for my team.
5/ Remove partially the useless crap in ir_module_category_data.xml
6/ Sort access rights groups on users form according to its parent category
closesodoo/odoo#29362
Signed-off-by: "Yannick Tivisse (yti)" <yti@odoo.com>
When calling the initial (create / default_get) onchange, the SSF
would send the list of fields in whatever order was provided by the
fields map of fields_view_get.
The web client uses view ordering, and it turns out some uses / tests
have dependencies between onchanges (e.g. _create_payment in
test_account_reports) which break on some orderings of the fields.
Send the initial onchange using view-ordered fields in the SSF as
well.
closesodoo/odoo#31494
When creating a new customer, the selection list for the state is empty
unless the country is filled in.
This is an issue since users usually fill the address fields in the
sequential order: street, city, state, zip and then country. Since no
state proposal is displayed, users tend to create a new state.
Introduced in 5fcf891e07.
opw-1941579
closesodoo/odoo#31273
To edit a view on the website, we use the branding mechanism.
This mechanism adds informations to node which can be edited about how
or where the change should be saved, for example:
```
<template id="a">
<div><b>hello</b></div>
</template>
```
might be rendered to someone that can edit it:
`<div data-oe-model="ir.ui.view" data-oe-id="5" data-oe-field="arch"
data-oe-xpath="/div[1]"><b>hello</b></div>`
when something is changed: we will send the modified content, the view
id (eg. 5 for view `a`) and the xpath in this view of what is replaced.
If a view is overridden, there is mechanism to distribute the branding
to children, for example:
```
<template id="b">
<div>
<b>hello</b>
<div>
</template>
<template inherit_id="b">
<div position="inside">
<b>world</b>
</div>
</template>
```
The branding can't be on the parent div that will contain other content,
because the other content is in another template and should not be saved
in template `b`, so this would be rendered like this:
`<div><b data-oe-model="ir.ui.view" data-oe-id="6" data-oe-field="arch"
data-oe-xpath="/div[1]/b[1]">hello</b><b data-oe-model="ir.ui.view"
data-oe-id="7" data-oe-field="arch" data-oe-xpath="/div[1]/b[1]"><b>
world</b></div>`
This changeset fixes two issues:
- if we have a primary inheriting view: the xpath are wrong in the
primary inheriting view part, they are computed on the view applied on
its inherit_id; the part of the inherit_id view have the primary
inheriting view ID instead of inherit_id view id.
- if we have `<div t-call="..."/>` in a view, the branding of view
should be distributed to children and not affect t-call part: this was
done for `<t t-call="..."/>` but not for `<anyothertag t-call/>`.
The added test failed on all assertions before the change:
- "test_branding_primary_inherit" would not distributed
- "test_call_no_branding" would distribute branding on `t-call`
opw-1937757
closes#31039
Depending on the scale, the number of units to add to today to
compute the default period. Examples: An offset of +1 in default_scale
week will open the gantt view for next week, and an offset of -2 in
default_scale month will open the gantt view of 2 months ago.
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
When users create an automated action to trigger when a record is updated,
they assume each update is 'atomic' in some sense.
It is not the case, as one write may trigger many write, some in recompute.
As a result, any update may trigger a dozen actions (or more).
We add a field wich allows us to specify which field we want to watch.
For instance, you could select the field 'state on quotation',
and thus only action would be triggered on confirming the quotation.
The link_field_id is a field that allows to link a record of the source model
to a new record of the target model, through a many2one.
However many target records can be created, so every one of them
(except the last) ends up orphan.
We allow for one2many and many2many fields to be used,
and in these cases we add the newly created record to the list.
opw 1910671
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
Let the database be in multi-company with unshared contact catalog.
Let F be a filter "('partner_id', 'not ilike', 'string')" on invoices.
If there is a contact which parent belongs to another company,
then this parent cannot be read.
Thus the name_get on partner can create an access error.
As a result applying the filter F would fail and return no results.
It generally doesn't make much sense to have a contact company X, which belongs
to the Odoo Company OC1, while its child contacts are in another Odoo company,
since many fields are directly computed from the parent.
However it is useful to have X belongs to no company, while it has child
contacts X>Yi belonging to company OCi.
In the first case it can create access errors interrupting the normal flow of
operations, while the latter should not.
To forbid the first case while allowing the second, we synchronize company_id,
but add a special case to ignore it if it set to False.
Note that PR#30997 should be used in case the name_get causes an error for
another reason that is deemed a legitimate use-case.
opw 1933862
closesodoo/odoo#31364
In small devices, onboarding bars are displayed vertial, which
takes too much screen space, and user has to scroll down
a lot to view actual content.
This commit improves the behavior by showing onboarding bars
horizontally (with scrolling) in small devices also, and thus
occupying minimal screen space.
task: 1929048
closesodoo/odoo#30823
Before this, groups on non-stored inverse fields were not checked upon write.
The impact on existing fields is pretty small, since the inverse methods of
those fields are subject to access rights on the records they use.
closesodoo/odoo#30357
This is the first step to a more comprehensive handling of company-dependent
fields which are ir_properties.
With model-specific access rights, users should be able to read/update a
company-dependent field no matter their access rights on ir_property.
Before this commit, a user having access to res.partner, but not to ir.property
couldn't write on property_account_receivable/payable just because he couldn't
write the corresponding ir.property. After this commit, he can.
OPW 1923345
The view has been rewritten from scratch so the doc and the RNG validation
needed to be adapted.
Co-authored-by: dmo-odoo <dmo@odoo.com>
Co-authored-by: aab-odoo <aab@odoo.com>
Co-authored-by: jat-odoo <jat@odoo.com>
See odoo/enterprise#3437
Task 1856235
* = account, purchase, website_sale_comparison, website_sale_wishlist
Raw Image & Mixin
=================
Previously, the main image from a product was stored resized. This caused
inconsistencies with the size of the images on ecommerce: the main image was
resized, but the extra images were not.
Now, we always store all raw images, thanks to the new mixin. This way, product
images that were created before the installation of ecommerce will be ready to
be used in ecommerce without any other change.
We also store the resized versions instead of computing them on the fly: this
will take more disk space, but significantly increase the speed of the
pages when displaying images, as well as reduce server CPU load.
Images on variants
==================
Previously, it was only possible to set the extra product images on a template,
and not on a variant.
Now, we allow extra images also on the variants, this gives more flexibility to
the user.
Both extra images on template and variant have been given a sequence field to be
able to sort them easily.
On /shop we always display the image of the template for performance reasons.
On /product we never display the image of the template, unless the variant has
no image, then the template image is the fallback.
Carousel
========
The carousel view has been cleaned and improved:
- remove the duplicate XML that was created with the product configurator fix
- use a single loop from a single source to get all the images, instead of
merging the different sources in the view with complex conditions
- improve the HTML structure, reduce the CSS with appropriate classes
Preview Image
=============
Both in website and backend: make better use of `preview_image` to display
a small image whenever possible, to reduce download size for the end user.
task-34045
PR: #30656
Co-authored-by: Parth Gajjar <pga@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
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
[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
Adding a new rule to verify that precision_rounding is positive.
Before this commit:
when a precision_round was 0 or smaller than 0 the float_utils
functions gave as results:
* float_is_zero(0.0, precision_rounding=0.0) -> False
* float_round(1.25, precision_rounding=0.0) -> 0.0
* float_compare(1.0, 1.0, precision_rounding=0.0) -> 1
These results where at least not correct at worst not logic.
Now, the function raises an error when the precision_rounding
is not positive
When merging 2 partners, we could want to sum fields instead of
keeping one of the values. Example: Loyalty Points
This commit adds the necessary support to achieve this.
This commit is related to task #1869488.
closesodoo/odoo#30141
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.
Now that we have proper support for RTL language, add an Arabic language with
code "ar" (while the only possiblity before was ar_SY).
Use ar_AA code as Arabic unitag.
In master, the ar_SY could be removed as no need to have both.
Add Bengali language
Fixesodoo/odoo#31165closesodoo/odoo#28640
In the overrides of _name_search we should avoid creating domains with
huge lists of ids as it is inefficient.
We can also make sure that we optimize the empty search as in this case
the custom domain doesn't make sense, we can simply search on an empty
domain and, thanks to the limit argument, still keep a fast query.
Linked to task 1918906
Thanks to @odony and @nseinlet
closesodoo/odoo#30155closesodoo/odoo#30887
