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
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
Purpose
=======
We would like to be able to manage multi contracts payslips and contract transitions.
Specification
=============
General flow:
1/ Benefits are generated based on contracts's calendar.
2/ When validating additionnal benefits, calendar.attendances are created in the contract's calendar
3/ Create one payslip per contract in state [open|pending|close]
4/ For each payslip, generate worked day lines based on the contract's calendar
New Constraints:
1/ An employee cannot have more than one contract at the same time (excluding draft, closed and cancelled contracts).
2/ A leave cannot overlap multiple contracts.
3/ A contract cannot have starting and ending dates such that a leave become in the middle of
two contacts.
New state for a contract: Incoming. It means it's ready and will be running soon.
An incoming contract automatically becomes 'Running' if the start date is passed (cron)
Number of hours and days are always correct (according to the contract's calendar) on payslips as the
flow starts from the contract's calendar.
However, it is not correct in the Time Off app because it's counted based on the employee's calendar.
The number of days/hours for hr.leaves should be computed according to
the contract at the time of the leave.
e.g. If I currently work full time and I request 2 weeks off next month where I'll be working only
3 days/week and 5hours/day (other contract), It should count 6 days and 30 hours.
- in hr.benefits form view show the contract (below employee field)
TaskID: 1903483
closesodoo/odoo#30181
This commit improves general usability.
Specification
=============
Screens usability:
1/ Benefits
1.1/ Calendar
- Add a sidebar filter to filter employees. The filters are saved per user.
If no filter exists for the user the 'Everybody' filter should be true by default.
- Generate benefits when clicking on the menu -> remove the wizard (popup): generate benefits for all running contracts
- Once generated, don't show again the generate benefits button: only show the Validate button
- Generate Payslips button: remove the wizard. It generates payslip of validated benefits
and jumps to the payslip batch form view.
1.2/ Form:
- rename: Start into "From"
- rename: End into "To"
- rename: Hours into "Period" (add 'hours' as unit on the right of the field)
2/ Payslip
2.1/ Form:
- Remove Payslip stat button.
- a computed payslip should be editable
2.2/ List:
- show: Reference | Employee | Batch Name | From | To | Gross Salary | Net Salary | Status
- In action buttons add a "Confirm" to confirm multiple payslips
- add a quick search on contract
- filters: rename 'draft' into "To Compute"
- filter: add "To Confirm"
Menus:
1/ Salary Computation
- Benefits (object: hr.benefit ; view: calendar, list, form, pivot. Group: hr officer ; filters: group by employee in the view)
- Payslips (objetc: hr.payslip ; Views: list, form, pivot. Group: hr officer ; filters: last batch ; Sort: employee name alphabetically)
2/ Employee Payslips
- Batches (objetc: hr.payslip.run ; Views: list, form. Group: hr officer ; Sort: creation date (last one first)
- All Payslips (objetc: hr.payslip ; Views: list, form, pivot. Group: hr officer ; filters: no filters; Sort: employee name alphabetically)
3/ Configuration
- Settings
---Salary---
- Rules
- Structure
- Contributions Registers
---Benefits---
- Benefits Type
---Repository---
- Employees (list)
- Contracts
When a benefit linked to a leave is cancelled, it should refuse the leave.
When a payslip batch is deleted, also delete associated payslips.
+ Refactoring of benefit js to use "Odoo style" event binding.
Purpose is to clean the use of tracking parameters on fields. Parameters are
merged and is now tracking=<int> or tracking=True.
This commit is linked to task ID 1903814 and PR #28430.
In Belgium, we have the concept of time credit and parental leaves.
Globally the person keep full time rights and the initial contract
is always signed on a full time basis. But an avenant with the new
time schedule must be signed.
A new wizard on contract allows to manage credit time. We can
specify the start and stop date, the new calendar and the work
time ratio. The new wage will be computed.
After validation, the current contract will be duplicate two times,
one modified for the time credit contract and the second for after
the time credit period. The current contract will have end date at
the beginnig of the time credit period.
TaskID: 1924200
Purpose
=======
This method has nothing to do on the payslip model.
Specification
=============
Move the method on the hr_contract module, on the hr.employee model.
Rename the method and return and recordset instead of a list of ids.
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Add some private information on the employees like:
- Certificate: Bachelor, Master, Other
- Place/Date of birth
- KM Home/Work
- Emergency Number/Contact
- ...
Also move some already existing private information from hr_contract to hr.
Purpose
=======
In contract, track fields (create a note, no need subtype. it is just for the history)
- wage
- fuel_card
- meal_voucher_amount
- representation_fees
- additional_net_amount
- retained_net_amount
- commission_on_target
- ip
- car_id
- internet
- mobile
- mobile_plus
- final_yearly_ cost
Prakash Prajapati