Compute notice duration and if the notice duration is not respected,
a report about termination fees is generated.
At the end of the notice duration, we can generate a certificate
about time off not taken and an other about time off for the next
year.
TaskID: 1914556
If validation type is set to `no_validation`, checking
if a target state is achievalbe should bypass
normal checks for the user's own leaves.
Otherwise, ir.rule raises an AccessError as the user
doesn't normally have the rights for leave in
state `validate`.
When this method is called in the context of an onchange
`self.ids` is an empty list.
This is a problem when calling `holiday.check_access_rule('write')`
because it does not find any valid holidays and thus raises an AccessError.
For usability purposes, it's better to set a structure type
on a contract (eg: CP200: Belgian Employee) instead of having
to choose between 'Belgian Salary', 'Double holidays', ...
In order to implement the same features both in the calendar and in the
gantt view, we need to extract the behaviours that will be common into a
mixin.
TaskID: 1947281
If there are no employee set on the allocation request and if the user
is a leave officer, don't check the access rights as it would lead to
a traceback.
Currently, when a leave is validated, an `account.analytic.line`
is automatically created. However, the approver may not have
the access rights to do so.
This commit fixes the issues by using sudo to generate the line.
Some module can inherit leave models and override some methods.
The overridden method could access some models which require other
access level.
In this case, the access issues would not be found by tests because
other modules are not yet installed.
e.g.
Recently, the `_create_resource_leave` was overridden in hr_payroll and
is reading the employee's contract. A HR user approving a leave
would raise an access error because he doesn't have contract rights.
If the tests would have been executed post install, this bug would
have been detected.
This commit changes the way benefits overlaps are detected.
Currently, all benefits are read from db and the
overlap detection is done in Python.
After this commit, use a single sql query to
only retreive overlapping benefits.
The query takes advantage of the postgresql
range type `tsrange` and the intersection operator
Performance improvements:
Tests with 500 employees and benefits generated for
15 months (~300000 records in the table)
Conflict detection over 1 month (~20000 records)
=> ~5X speedup (from more than 2s to less than 0.5s)
Contract managers should be able to create/manager employees.
This make sense when a contract manager hires someone.
He first creates the employee, then his contract.
This also allows contract managers to access private addresses
by transitivity.
This is also intended to allow a contract manager to set
a driver (private partner) on the employee's company car
or to access `km_home_work` for transport reimbursment
(l10n_be_hr_payroll).
Purpose
=======
Currently, groups `hr_holidays.group_hr_holidays_[user|manager]`
and `hr_payroll.group_hr_payroll_[user|manager]` are independant.
A member of payroll groups is not able to approve/refuse a leave.
This is a problem as they should be able to approve/refuse leaves before generating payslips.
This is the point of `hr.benefits`: a global way of managing
attendances and leaves before generating payslips.
Specification
=============
Payroll groups should imply the corresponding
holiday group.
1. User
`hr_payroll.group_hr_payroll_user`
implies
`hr_holidays.group_hr_holidays_user`
2. Manager
`hr_payroll.group_hr_payroll_manager`
implies
`hr_holidays.group_hr_holidays_manager`
Purpose
=======
Currently, linking a benefit type and a leave type is done through
the leave type form view.
This is anoying because it requires to first create the benfit type,
then go to the leave type and link it.
Moreover, linking is the role of a payroll manager which should be
able to do it from the Payroll app.
Specification
=============
Add a One2many field `leave_type_ids` on `hr.benefit.type` to
allow to link a leave type when creating a benefit type.
An employee with only the contract user group should be able to create
a contract. It implies to be able to read a salary structure and
a salary structure type.
If a user is member of `hr_contract.group_hr_contract_manager`
but not member of `fleet.fleet_group_manager` some access issues arise
The issues are related to the `car_id` field of `hr.contract`
because the user has no access rights for `fleet.vehicle`.
Fix to solve the issue:
Make all car related field of contracts available
to fleet manager only.
If the contract manager want to be able to manage cars on
contracts, he must manually be granted fleet manager access.
This is a requirement if the contract manager want to use the
company car feature.
When a `hr.leave` is approved, a `resource.calendar.leave`
is created in the employee's calendar and in the
contract's calendar if it's different.
However, a user in `group_holiday_user` but not in
`group_hr_contract_manager` does not have access rights
to read a contract.
This leads to an `AccessError`
Fix: use `sudo` to read the contract.
Currently, a Team leader can't approve a leave of an employee
in his team if the leave type requires an allocation.
The reason is the `ir.rule` for `base.group_user` restricting allocation
read access to only your own allocation (`[('employee_id.user_id', '=', user.id)]`)
There are no `ir.rule` for group Team leader.
Therefore, a team leader can't read allocations for his team members.
Fix: add an `ir.rule` to allow a team leader to read allocations
of employees in his team.
+ add associated tests
1/ Remove the parent-children relation on salary structures
Currently it is difficult to see what rules are applied on salary structures.
Most of the structures are inheriting 3 rules (Basic, Gross, Net) from the
'Base for new structures', and those rules are not shown. Same issue if a
structure has another one as parent (as in the French localization).
This bring more annoying issues:
- Since the saas-12.1, we can already set different accounts for different
companies on the salary rules for which we want to post journal entries.
But for the parent rules, like the 'NET' amount, it's impossible to post
the journal entries on different account for different salary structures.
(eg: for CP200 employees and CP200 workers). As the rules are following
a M2M relation on the structure, we have to remove the parent_id and to
recreate all the rules in the final structure.
- If we are not at ease with the M2M relation (which is the case for most
of the end users), we will simply modify the rule on the parent structure.
This was already done on the French localization on which we modified the
code, sequence and the name. This could have some desastrous consequences
as this will break the order on which the rules are computed for other
structures for the sequence, or break other integration with the payroll
as we also modify the code, for example the salary configurator.
As this parent-children relation on structure could cause several issues
difficult to spot and as this is quite difficult to correctly visualize the
structure composition, it is better to remove it and define all the rules
inside the structure itself. This improves also the code readability as we
are not trying to recursively retrieve the rules and find a proper sequence
inside them.
2/ Make the rules on the salary structure a o2m instead of a m2m
The issues described just above indicates that it would be better to remove
the M2M relation between salary structures and salary rules, and make it
a O2M relation instead. That way, no more confusion and misconfiguration of
the rules fields (code, sequence, accounts, ...).
3/ Remove the parent-children relation on rules
A salary rule can have a parent salary rule. This mechanism, which is
not obvious at all for an end user allows to specify a parent rules.
If the condition is met for the parent rule (eg: the employee has at least
1 child), all the children rules could be applied (eg: Deduction of 90 euros
if the number of children is between 1 and 1).
Visually it doesn't make a lot of sense, as it displays one line with an
amount of 0 for the parent, and one line with the real amount for each
applied child. On the other hand, no child rule is linked to the structure
and an end user has to click on the parent rule, to see the children and
understand that something mystic and hidden is existing.
This is equivalent to define as many classic rules as we have children, or
even better, define 1 rule that will compute the real amount directly,
as the number of children can be accessed from the localdict when computing
the salary line.
This commit also removed the relation.
4/ Clean some brols in the code (technical)
The 3 first points of the spec allow us to clean a little the code readability
and complexity.
5/ Adapt all the localizations for these changes
All the localizations are impacted by those changes. What is done in this commit
is mainly:
- l10n_be_hr_payroll: Make 3 separated files for the 3 existing structures (the
fourth one, belgian worker, is not correct and is removed). For each
structure, define explicitely the rules (in the correct order by sequence).
This multiplies the total number of rules as some of them were shared (like
the withholding tax rule for example), but all the code that is supposed to be
modified each year/quarter/whenever the government decides to modify the law
has been moved into a python file, and is available the computation context.
This will also allow us to update the computation rules without having to
update the module.
- l10n_fr_hr_payroll: There were 3 rules following this scheme:
Base for new structure
|
Basic structure
|
----------------------
| |
Cadre Non-Cadre
All the rules parent rules have been duplicated into the 2 remaining
structures, cadre and non-cadre. There were a lot of parent-children relations
between the rules that have been adapted to the new model.
- l10n_in_hr_payroll: There was a lot of rules in data, and a structure in demo
data, which was using 4 or 5 of these rules. As the rules doesn't seem to make
a lot of sense altogether, everything was moved in demo data.
6/ Introduce a new Salary Structure Type model
Currently we have a model hr.contract.type with a M2O on the contracts. This has
never been used in 9 years and is removed in this commit. On the other hand, we
would like to define a new model hr.payroll.structure.type (eg: CP200 Employee),
which will line all the salary structures the Belgian localization could bring
(Classic salary, double holidays, 13th month, ...). This field is defined on the
structure, and is displayed on the contract (as the same place than the contract
type we just removed).
On this model we could also define some fields like:
- The default pay period: Selection field, default = monthly. This is applied on
the contract when selecting the structure.
- The Working Schedule, m2o. This is applied on the contract when selecting the
structure
For example, on the 'commission paritaire' for teachers, we could set the
default pay period to 'Every 15 days' and the working schedule to '19 hours /
week'. Every contract under this structure would take those values.
Migration
=========
For a migration point of view:
- All the rules that had a parent_rule_id should be set to
appears_on_payslip=False. The column parent_rule_id can be dropped afterward.
- All the rules that are coming from a parent structure or higher should be
duplicated and the field 'struct_id' should be set on the current structure.
The column parent_id can be dropped afterward.
- All the rules that were defined on the structure should have the field
'struct_id' defined on them.
- The rules that are not linked to a structure should be unlinked.
- The column type_id on the contract could be dropped, no need to keep the
values too.
- A default structure type is defined in data ('Employee'). This could be set to
all the existing structure for the newly created 'type_id' field.
TaskID: 1942832
Since the bootstrap update that was merged with
https://github.com/odoo/odoo/commit/754ec4450832dceef83c3a0abb79401f2e7ec05d
the customize theme dialog was showing transparent colors for the
headings. This was because bootstrap changed the value of the related
variable from 'inherit' to 'null' to avoid an useless css rule if the
headings are supposed to have the same color as the body text.
closesodoo/odoo#31909
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose
=======
This follows up commit d946b7a85d that cleans
wrong uses of sAnimations for non-animated behaviors.
closesodoo/odoo#31794
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When the user has not set any image, it now displays the default
user image placeholder instead of the image placeholder in livechat.
Task-ID 1924666
closesodoo/odoo#30821
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Forbid locking the fiscal year or period in case there is an open POS session into it. Without that, it will be impossible to close these sessions, as the lock date will not allow posting accounting entries for them.
Also forbid to create a session before lock date, as it would be impossible to close.
closesodoo/odoo#28257
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Since the switch to jQuery 3, Odoo uses native promises in its JS. Some
mistakes were made in the website app during conversion from old jQuery
deferred to native promises.
- `this` -> `self` when wrapping in a promise
- `.always(fct)` -> `.then(fct).guardedCatch(fct)`
- a function returned sometimes a jQuery deferred, sometimes a native
promise. This made the caller fail when using `always` or fail
when using `guardedCatch`
closesodoo/odoo#31887
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This error is there to help developpers realize their view has not
been loaded due to an error.
However, we have cases where we define actions containing views
that only exist in Enterprise to avoid creating an entire bridge
module just to add one view to an action.
The error was triggered in this case which resulted in a red build
for the click all runbot test, even though this was not really a
true error, as it was intended.
This commit changes the error to only appear in debug=assets such
that it will no longer put the click all runbot tour red while
still providing help for the developper trying to debug his view
since he will need to be in debug=assets to debug his view anyway.
closesodoo/odoo#31884
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Let's assume the following scenario on an action with two multi
records views (e.g. kanban and list). In the kanban view, activate
a domain or groupby, switch to list view, remove the domain or
groupby, switch back to kanban: the domain or groupby is still
applied (even though it's no longer displayed in the search view).
This is due to the jQuery update (ab56e637b7) and the use of
native Promises (always async) instead of old jQuery 1.11 Deferreds
(which where sync when already resolved). In the new version, the
domain/context/groupby were added to the params a 'tick too late',
so the view was updated without that information (and thus the old
domain/context/groupby were kept).
Issue reported on the jquery update pad.
closesodoo/odoo#31859
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
The table edition feature of pos_restaurant was using an old lib
that was never updated to newer versions of jQuery by its author.
For unknown reason, this library went unnoticed when we updated our
codebase to jQuery 3.
Since this library is impossible to update per se, I decided to
remove it entirely and replace it by calls to jQuery.ui.
However, the point of this lib was to handle touch events, which
jQuery.ui does not. For this, this commit introduces a new
library which translates touch events to their click counterparts.
Tested on:
- Chrome (Windows, MacOS, Linux, Android, iOS)
- Firefox (Windows, MacOS, Linux, Android, iOS)
- Safari (MacOS, iOS)
- Edge (Windows, iOS)
- IE11 (Windows)
- Samsung Internet (Android)
closesodoo/odoo#31719
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Some customers need to have a float instead of a in for the percentage
of the margin taken on the delivery. So we modified the integer value
into a float.
Until now, only fedex was providing return label printing, and as we
want to integrate it with other carriers, we have mande a generc
mecanism to easily implement it with new ones.
We've also added an option that allow to print return label from portal
if one has been generated on delivery.
The portal template that add the tracking number on the picking in the
sale order report in portal is still in website_sale_delivery, even if
the portal does not need the website anymore. More over, the inherited
template has been moved from website_sale_stock to sale_stock.
So to be consistent and not forcing having website for a feature that
doesn't need it, we move this template inheritance in delivery
Purpose
=======
The 'service_tracking' selection field on the 'product.template' model in the 'sale_timesheet' module
had its 'task_new_project' option renamed to 'task_in_project'.
If one or more sale_order_line have a product configured with this option, a new 'project_id' field appears
on the sale_order under the 'Sales Information' section.
When a project_id is selected, the analytic account on the sale order is automatically changed
to this project's analytic account.
This allows handling more use cases on sale_order:
- If a sale_order_line has a service product with that new option and no project_id configured on the sale_order:
-> create a new project based on the configured project_template_id and then create a task in that project
(same behavior as before)
- If a sale_order_line has a service product with that new option and a project_id is configured on the sale_order:
-> directly create a task in the selected project_id
The behavior does not change for the 3 other options ('no', 'task_global_project' and 'project_only').
Specs
=======
- Add project field on sale order in "other infos" tab, shows only when a product on the SO has the option activated
- If projec is selected on SO, create task in this project, otherwise it creates a new project (as before)
- Rename 'task_new_project' into "task_in_project"
- Allow to have the new option with project template
- Selectable projects on Sales Order are `billate_type` in 'no' and 'task_rate'
- Never link SO's project to SO or AA
- Add onchange on project_id to select this project's analytic account on the SO
- Non stored computed field to check if at least one SOL has the new option
Use cases
- 2 SOL with new option (no template) will create 2 tasks in SO's project
- 2 SOL with new options (one no template, one with) + 1 SOL "create new P no T" --> create 2 tasks in SO's project and one new project
Task #1915660closesodoo/odoo#29772
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Task #1915660
Purpose
=======
Analytic Account field of a project should not be visible for non-members
of the "analytic.group_analytic_accounting" group.
This is now consistent with the other analytic account fields of the application.
Task #1915660
Purpose
=======
If one or more sale_order_line have a product configured with this option, a new 'project_id' field appears
on the sale_order under the 'Sales Information' section.
When a project_id is selected, the analytic account on the sale order is automatically changed
to this project's analytic account.
This allows handling more use cases on sale_order:
- If a sale_order_line has a service product with that new option and no project_id configured on the sale_order:
-> create a new project based on the configured project_template_id and then create a task in that project
(same behavior as before)
- If a sale_order_line has a service product with that new option and a project_id is configured on the sale_order:
-> directly create a task in the selected project_id
The behavior does not change for the 3 other options ('no', 'task_global_project' and 'project_only').
Specs
=======
Add project field on sale order in other info tab, shows only when a product on the SO has the option activated
if projec its selected on SO, create task in this project
Tech Spec (jem)
=======
On product:
- rename 'task_new_project' into "task_in_project" (help message precise either new project (based on template) or
SO's project is prior
- allow to have the new option with project template
On sale order:
- non stored computed field to check if at least one SOL has the new option.
- if so, display project field
- selectable project are billate_type in 'no' and 'task_rate' (TBC for the 2nd)
[awa: also add 'analytic_account_id' != False in domain]
- setting project on SO should change the AA of the SO.
[awa: add onchange on project_id to select this project's analytic account on the SO]
- Never link SO's project to SO or AA
[awa: do not touch the project_id's sale_order_id and analytic_account_id fields for this use case]
- 2 SOL with new option (no template) will create 2 tasks in SO's project
- 2 SOL with new options (one no template, one with) + 1 SOL "create new P no T" --> create 2 tasks in SO's project
and one new project
Actually, when running browser_js tests, the test automatically fails
when a console error is seen.
In some cases, an exception can be thrown during a tour but without
console error. In that case, another type of devtools protocol event is
fired: Runtime.exceptionThorwn. This event is not catched by the
browser_js test.
With this commit the above mentioned event is catched and the test is
directly considered as failed.
closesodoo/odoo#31555
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
During the event tour, the save button is clicked before the drag and
drop is finished and cause an uncaught exception.
With this commit, an extra trigger is used to check the presence of the
dirty flag that is set when the page is changed and is ready to be
saved.
When a move is created in a picking through the scrap button, it must
not be visible in the picking, and should be accible through the
stat button showing the srap.
Now to hide, those moves from the picking view, we are checking that the
move has a different picking type than the one on the picking, which can
lead to invisible moves, that are not in the picking view because they
have a different picking type and not in the scrap stat button because
they don't have scrap object.
To fix this behavior, we are hiding from the picking the ones having a
scrap object linked instead of the one having a different picking type
closesodoo/odoo#31810
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Yannick Tivisse