Purpose
=======
The "first contract date" is a usefull information for anybody who onboards
new colleagues. Issue: this information is not on the "public employee" and so,
visible only by hr officer (minimum).
With this task, we would like make this field public and visible by any internal
user in the system. In this way, we don't have to provide too many access rights
to any employees.
closesodoo/odoo#73552
Taskid: 2584098
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- hr_contract: Add kanban view on contract history action
- hr_contract: Display the avg wage, not the sum on aggregates
- hr_contract: Improve contract history list view
- hr_contract: Improve contract history tree view
- hr_contract: Improve contract history search view
- hr_contract: Display wage on contract kanban view
- hr_contract: Improve contract tree view
- hr_contract: Improve contract search view
- hr_contract: Make hr_responsible required
It is useful in multiple HR flows.
- hr_contract: Improve contract history form view
- hr_contract: Improve contract form view
- hr_work_entry: Improve work entry computed name
- hr_work_entry: Improve work entries tree view
- hr_work_entry: Improve work entry type form view
closesodoo/odoo#72402
Taskid: 2558171
Related: odoo/enterprise#19124
Related: odoo/upgrade#2583
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Models -> Fields
1) fleet.vehicle -> description
2) fleet.vehicle.log.contract -> notes
3) hr.job -> description
4) hr.contract -> note
5) hr.leave.allocation -> notes
6) hr.applicant -> description
7) lunch.product -> description
8) lunch.order -> product_description
9) lunch.product.report -> description
Task Id: 2499504
X-original-commit: afe52b050a7667f3f20696cd48cd922f635a941c
Hide fields related to belgian localisation when not using a belgian
company.
Task Id: 2496597
closesodoo/odoo#69691
Related: odoo/enterprise#17881
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This reverts commit 825b533ec964fd8a9923dd4d2091f122b92d8759.
For the following reasons:
- This is a behavior change on a stable release. See our stable policy:
https://github.com/odoo/odoo/wiki/Contributing#what-does-stable-mean
- If a contract end date is set, it's erased when moving the contract afterward.
- There is a cron which is moving the expired contracts automatically,
this will rewrite the end date on it, which is not a big deal, but this
is useless.
- Modifying the contract end date also unlink all the work entries that are
outside of the new contract period. If there is an open payslip, it also
recomputes the worked days lines, and the payslip lines.
That way, it's possible to recompute a payslip by introducing unpaid
time off inside of it. If the payroll officers are checking the payslips
at that time, and don't notice it (already checked, etc...), then at the
validation, this could lead to some more serious issues (wrong net salary
paid to the employee, wrong accounting entries, wrong declaration to the
state, etc).
If the contract end date is badly configured, this is normal that the
reporting is wrong. No need to add some magic that people don't understand,
that could lead to wrong behaviors later on the process.
closesodoo/odoo#68541
X-original-commit: c34b6bc3d0d25e8b8b1bcb6684331627b823f57d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
When we want to retrieve all the contract (running for instance), we
don't care about the fact that the employee is archived or not.
For example when we generate the work entries to generate the payslips,
we actually pay the employee, even if he's archived (which is the
normal flow).
closesodoo/odoo#66836
X-original-commit: 262bf8598f9d885382c05e523543019767b521bf
Related: odoo/enterprise#16677
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When changing a contract's state to "Expired", if the contract has an
end date, the latter is not updated. As a result, contracts' reporting
contains some error.
To reproduce the error:
1. Create an employee E
2. Create a contract C
- Employee: E
- Start date: in the past
- End Date: in the future (! at least after the current month)
3. Set contract's state to "Expired"
4. Go to Employee > Reporting > Contracts
5. On pivot view, change the rows:
- Total must be split into "Date > Month"
- Current month must be split into "Employee"
Error: on current month, "# Departure Employee" of E-employee is 0. It
should be 1. This value's computation is based on `contract.date_end`,
but when changing the state to "Expired", the variable will not be
updated if it already has a value. So "# Departure Employee" will be
equal to 1 for the month of end date defined on step 2, instead of
current month.
Note: The fix result can not be directly tested. The end date must be
done for the departure to be effective (`contract.date_end` < 'today').
Since this fix updates `contract.date_end` to 'today', "# Departure
Employee" will not count this contract until the following day.
OPW-2445504
closesodoo/odoo#66002
X-original-commit: 3cfc1e7dc3ad8396a92d12f74b65485e5938077a
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Purpose
=======
Currently there's no easy way to retrieve all the contract using a given
calendar.
closesodoo/odoo#65621
Related: odoo/enterprise#16157
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Otherwise, they may crash or be incorrectly verified when
creating/updating recordsets containing multiple records.
Also improve the constraint error messages to be more detailed.
When possible, use a sql constraint instead to speed up the records
validation.
Task Id: 2328664
COM PR: https://github.com/odoo/odoo/pull/55525
ENT PR: https://github.com/odoo/enterprise/pull/12250
Before this commit:
It was complicated to manage the contracts as they were all displayed in
one view.
When the contract was a time credit one (which is by definition a temporary
situation) the data used was based on the time credit and not on the full time
equivalent. This usually forced the HR to create fake new contracts without
time credit for the appraisals.
After this commit:
A new report will ease the followup of contracts with the time running.
It comes with a new view that highlight the reference information which
allow to easily manage credit time. Simulation is also made on FTE data which
eases HR work.
This commit also fixes a bug in the simulation with the meal voucher (only one
was taken into account in the summary right panel.
The wage on signature is now populated when the document is signed.
Closesodoo/odoo#58120
Related PR: odoo/enterprise#13384, odoo/upgrade#1802
task-2326407
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Impacted modules:
hr, hr_contract, hr_recruitment, hr_payroll, fleet, hr_skills, hr_appraisal, ....
Several onchanges have been converted to computed fields in the following modules :
Community :
- hr
- hr_contract
- hr_recruitment
- hr_work_entry
- hr_maintenance
- hr_expense
- hr_expense_check
- hr_holidays
- sale_expense
- account_analytic_default_hr_expense
Enterprise:
- hr_contract_salary
- hr_referral
- hr_payroll
- hr_payroll_expense
- test_l10n_be_hr_payroll_account
There are still 2 onchanges with complex behavior that couldn't be converted easily:
- an onchange that updates "tz" (timezone) that is defined as a related field
to "resource_id.tz". Apparently it is useless except to initialize the default
value of "tz".
- an onchange that updates "name" that is defined as a related field to
"resource_id.name".
the applicant.
closesodoo/odoo#45414
Taskid: 2169099
Related: odoo/enterprise#8572
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The field `medic_exam` is not used anywhere and can thus be removed.
closesodoo/odoo#49631
Taskid: 2239321
Related: odoo/upgrade#1075
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
+ Add helper method to retrieve the contract wage.
Those methods are supposed to be overriden in some cases.
closesodoo/odoo#48258
Taskid: 2222984
Related: odoo/enterprise#9454
Related: odoo/upgrade#980
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Even if you don't manage your payroll using Odoo, it could interesting to
categorize your contract (CP200, ...), in case you manage several kind
of workers or employees in your company.
TaskID: 2148537
An HR user (without any rights on contracts) could not open
an employee form view since it needs the `first_contract_date`
field which needs contracts access rights.
closesodoo/odoo#47561
X-original-commit: 14855eee0f9c5737ee5aaa792defe88e138e0d7d
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
Before this commit:
When we change a contract to stage 'open', we write this contract
on employee. But it causes error when it's a template contract
(without employee).
After this commit:
When we change a contract to stage 'open', we write this contract
on employee only if contract has an employee.
[FIX] hr_contract: Allow overlapping in template contract
Before this commit:
We check for all contract that there are no overlapping for a
same employee.
After this commit:
We check that there are no overlapping for contract with
employee.
[FIX] hr_payroll, hr_holidays: Avoid some constrains with company time off
Before this commit:
We can't create company (or team) time off if you have 2 or more
template contract in your database.
We can't create mutliple company or team time off that overlaps.
After this commit:
We can create company (or team) time off if you have 2 or more
template contract in your database.
If a time off is set across multiple contract, print those contracts
in error message.
We can create multiple company or team time off that overlaps.
closesodoo/odoo#45696
Taskid: 2196185
X-original-commit: 3fdada6f8f19ae7123d9b35b3e7c557d072c1bc0
Related: odoo/enterprise#8553
Signed-off-by: jbm-odoo <jbm-odoo@users.noreply.github.com>
Purpose fo the task is to improve the usability of hr contract and
automatic alert before contract expired
-improve sign demo data
-improve kanban state field in contract kanban
-improve contract Form view ui
-set first contract date on employee form
-added the date of last completed contract on the new contract
-improve signature request form
-create automatic activity before the week of contract expired date
closes odoo/odoo#40789
Task: 2049413
Closes: #40789
Related: odoo/enterprise#7454
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When a contract is closed, set the date of the day.
In the contract cron, ensure that all closed contracts have
an end date if it is followed by a new contract.
Add multi-edit on work_entry list
closesodoo/odoo#44118
Taskid: 2180263
X-original-commit: 0b5d8ce756eac904a040ca700f44ea860daefcb4
Related: odoo/enterprise#7991
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Make some fields editable in multi edit.
Some onchange are tranformed in compute fields.
id=2078674
closesodoo/odoo#39711
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When the many2xxx field relates to a model where company_id is required, set
this domain [('company_id','=',company_id.id)]
When the company_id field of the related model is not required, set this domain
['|',('company_id','=',company_id.id),('company_id','=',False)]
When setting the domain on a field which is in the treeview of a xxx2many field
evaluate against the company_id of the 'parent'.
Some constraints have been added on sereval models. Take a look at the complete
specification for more details.
TaskID: 2024446
Closes: #35266
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* account, hr_contract, hr_expense, point_of_sale, sale_margin,
website_sale_delivery, website_sale_wishlist
digits only works on Float fields, on Monetary fields it has no
effect:
- The column_type of a monetary field is always numeric
- It is not applied in `convert_to_column()` or `convert_to_cache()`
- It is not part of `description_attrs`, so it will not be included in
the output of `fields_get()`
closesodoo/odoo#35336
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Social secretariat is a Belgian concept. It does not make
sense to have this in the standard contract app.
Will be reintroduced in l10n_be_hr_payroll (or internal)
if really needed.
Move `job_id` in the right group to easily add fields
on the right with view inheritance.
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Purpose
=======
Having some usability check to be sure to make the pay
for everyone, and don't loose contracts.
We would like to remove incoming and to renew columns in
hr.contract and replace them by a kanban state. In employee, we would
like to add warning on the kanban to warn the hr responsible there
is no contract or a contract is about to expire
Specification
=============
hr.contract kanban:
- add a kanabn state
- it becomes red automatically when the contract is in running and expire in 7 days
- add aquick search in filter to filter on expered soon
- the kanban state can be changed manaually (in case of there is several rh)
- sort by contract end date set first (more close of today first)
Employee kanban
- add an red icon if there is no contract in Runnig status OR there is a
kanban state red in their contract (whatever the status).
- add a quick seaach on employee with warning
- State pending + green = incoming
- State confirmed + red = about to expire / to renew
closesodoo/odoo#33489
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
An employee and its current contract should have the same
calendar. Currently, if the contract's calendar is changed,
the employee's calendar is not changed.
In the same way, if a contract is created directly in `open`
state, the employee's calendar is not changed.
Finally, the calendar synchronization when the employee
contract is changed is only done in payroll, for no reason.
Specification
=============
Fix the three issues described above.
If the employee's calendar is nonetheless manually changed, a warning
should be displayed if there is a mismatch between both calendars.
- There's a constraint limiting the number of contracts an employee can
have.
This constraint take in account closed contract which cause issues.
For example if you have to sign a new contract for an employee with a
running contract, you'll have to close the current running contract.
But if this employee already has closed contracts, you won't be able
to close it since they are detected as ""running"" contracts.
closesodoo/odoo#33294
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
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
Yannick Tivisse