In https://github.com/oca/edi many module names end with "_oca" to show that it is the OCA alternative to another module with the same name. I think this is a nice convention, so I suggest to rename "payroll" to "hr_payroll_oca", and "payroll_account" to "hr_payroll_account_oca". Then in the list of modules, all payroll modules will be grouped together, starting with "hr_payroll".

What do you think?

When trying to install, i get a server error and a traceback with this message at the bottom

ImportError: cannot import name 'hr_salary_rule' from partially initialized module 'odoo.addons.payroll.models' (most likely due to a circular import) (/mnt/extra-addons/payroll/models/__init__.py)

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-17.0

Modules to migrate

• payroll
• payroll_account

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

Modules hr_payroll_cancel and hr_payroll_change_state.

Should we merge this modules logic into payroll module itself? Or maybe just provide this functionality in the base payroll module so we don't need that modules?

I don't think the point of maintaining more two modules whose purpose is to add the functionality of mass change states and cancelation. We can just plug-in this functionality to the base module.

What do you think?

In general, I think that payroll should have essential features only. I am not using:

• Contribution register
• Worked days
• Other inputs
• "Salary rules appearing on payslip" (details_by_salary_rule_category)
• Codes (I don't always need them, why are they required in salary rule, category & structure?)
• Child rules
• Python in salary rules (I use it now, but I would like to make a flexible alternative)

@nimarosa @mtelahun @pedrobaeza @percevaq
Are you using all of these features?
Is there any other payroll feature that you are not using?
Do you think that anything should move to another module, or be enabled with a setting?
Please write short answers!

CC'ing developers involved in change
@nimarosa @pedrobaeza @apps2grow

Module

payroll

Describe the bug

Hi guys, this change happened a few months ago but I only noticed it now when I updated my upstream sources and my unit tests started to fail.

PR #27 changed the sign of calculated hours and days of leaves to be negative. This is causing unit tests in my custom modules to fail.
I don't think the previous behavior was a bug, and even if it was I believe it's a bit late in the 14.0 life-cycle to be changing expected behavior now. Basically, this gratuitously changes previous behavior of the module without any tangible benefits to the wider community.

Expected behavior
That the module continues to function as it has before.

I'm glad to see this repo is actively maintained by OCA. It's kind of loss since V13 it was moved to EE.
This repo is become more complete and hopefully there will new other features coming soon.

One of my feature I think I can't find right now is to get the attendance days to be imported to worked_days. As default it shows the WORKS.100 but, it's good to calculate the total days from the attendance to payslip. Having overview about the attendance and the time off will help user to get rid the conflict between the scheduled.

The second, it would be good as well if we can compensate the receivable / payable that was created from Expense Module to be factored in payslip. Currently, we can use Inputs and fill the amount manually, but if we can import it automatically from the approved expense, that will be great. One of the use case I found is about deduct the payroll by the staff loan instalment.

Thanks for considering items for the next round.

Should I make an empty branch?

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-15.0

Modules to migrate

• hr_payroll_period - By @JuanyDForgeflow - #120
• payroll - By @mtelahun - #81
• payroll_account - By @mtelahun - #84
• payroll_contract_advantages - By @nimarosa - #98
• payroll_hr_public_holidays - By @nimarosa - #100
• payroll_rule_time_parameter - By @nimarosa - #104

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

hr.payslip has two fields with one2many relationship to hr.payslip.line:

• line_ids
• details_by_salary_rule_category - showing only lines with category_id, which is a required field
  So these fields are identical.

details_by_salary_rule_category is found only seven times in the code. Can we remove this field and replace with line_ids?

Why is there a separate page "Details By Salary Rule Category" in the payslip? All the info is also in "Salary Computation", right?

Hi friends,

What is the purpose of the contribution.register?

I appreciate this active payroll community! For version 15.0 I would like to explore ways to make the payroll easier to use, both for small and big companies. Possible tools for this could be a 15.0-dev branch and Google document/spreadsheet/survey/meeting.

My PR #51 could be a contribution to a 15.0-dev branch. It should not be merged with 14.0 since it is adding a new payroll dependency on the analytic module. As discussed in #31 it is not good to add new dependencies for the current users of the module.

To avoid maintaining two branches more than necessary, we can wait with this for a couple of weeks, to finish important improvements for 14.0.

Hello oca/payroll users and contributors.

This thread is to discuss migrations to v15 and v16. As you can see, the new v16 branch is now live and we still in the v14.

Since we are using v14.0 to do improvements and changes to the modules, I suggest we continue doing so until we think it's time to migrate to v15.0 and then to v16.0.
My approach here will be maintain the tree versions because i have clients that will continue with v14.0 for a while, but i think we should start with v15.0 migration soon.

From my end, i have some PRs that i wish to merge first in v14.0 before we start the migration so we can have this changes in following versions. I will try to include all this changes this week or the following.
If someone has something new or improvements that wish to include in the module, i suggest to do it as fast as possible.
So i think we can schedule deadline for starting migrations to other versions on 20/10/2022.

As i said, i will continue maintaining v14.0 version but also after migration, I will port any change in any branch to the other ones, so it will be good for all of us to include any changes you wish to include before this date, so we reduce the workload of backporting versions.

Any doubt or suggestion about migrations can also be addressed in this thread.
Kind regards to everyone.

Hello, I would like to know if there is documentation to deploy these modules in the system.

cc @FernandoRomera

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-16.0

Modules to migrate

• hr_payroll_period - By @nimarosa - #103
• payroll - By @mtelahun - #85
• payroll_account - By @mtelahun - #86
• payroll_contract_advantages - By @nimarosa - #99
• payroll_hr_public_holidays - By @nimarosa - #101
• payroll_rule_time_parameter - By @nimarosa - #105

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

Dear all,
Translation of this project has been locked in OCA Weblate for a long time. This causes many problems for us (end users). Would you check and open it?

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-14.0

Modules to migrate

• payroll - By @apps2grow - #20
• payroll_account - By @appstogrow - #25

Missing module? Check https://github.com/OCA/maintainer-tools/wiki/%5BFAQ%5D-Missing-modules-in-migration-issue-list

Hello, motivated by the chat we were having in #87 I open this issue to discuss possible solutions to safe_eval lack of security so we can stop exposing all python environment in a salary rule.

The main issue here is: safe_eval is not safe at all. It exposes real environment python objects and allows the user to run almost everything from a salary rule.

So I come up with 3 ideas that I think if we apply at least one of them it will improve security in the module rules:

1. We should write more standard options of calculations, so we can move the python mode to another module to be used only when necessary.

2. We modify safe_eval to not allowing write access to the ORM. Actually don't know how difficult this can be, but I think is an option.

3. We create a new salary rule coding language. It would involve a whole module change, but for me, is the more promising one, and I have some resources you can check to get an idea:

In python we have some libraries and derivates projects called "Python String Parsers" that in resume provide a whole package that parse strings and convert them to encapsulated python code (so it didn't expose the environment) and return the result of the operation. This packages will solve the problem since we will not write python code in the rule, we will be writing strings and functions from the parser library and the the package will take care of interpreting and processing the sting code, not exposing in any way the python environment.

For you to read I leave you some resources about it:

• ply: Lexx/yacc library. It could provide us with a internal language from rules. In the link you can also see projects writed with ply that could be useful for providing us functions to use in rules.
• pyparsing: it's a big module with all sort of functions and use cases. It can also provide us a string-like programming language to use in rules.

Also I leave some interesting article about eval safety issues. That is a problem with eval and safe_eval so that's what we should attack. Eval is really dangerous

So in resume I think we should take a look to all options. Also, and in a way of providing temporary security I will work in @norlinhenrik approach of locking the salary rule form from only a few cases or maybe a setting. So only trusted odoo users can edit rules.

Also I think #87 should be merged with the new payslip object fix, because adding it don't increment current security issues of salary rules, it's just another object and since we have access to all env in rules, I think we can tolerate this change. We should attack security issues from the root, which is python safe_eval not the objects.

Leave this thread to discuss with you @appstogrow @mtelahun , I can also create a new branch to work in this if you are willing to help me with this, since it's a big change and I don't have time to do it alone, I have the ideas so I think we can make a good team.. Let me know what you think and I can create a 14.0-new-rule-language branch and we can work in there until everything is ready.

Module

payroll

Describe the bug

Adding a manual value into "Salary Computation" doesn't recalculate other lines.

To Reproduce

Affected versions: tested on Odoo 13.0 and 14.0

Steps to reproduce the behavior:

1. Create new payslip
2. Click on "Compute Sheet" button to populate Salary Computation
3. Click on "Edit"
4. Click "Add a line"
5. Add new item "Bonus"

Expected behavior
While "Bonus" has code than BASIC, I expected to have all other lines computed, like GROSS which is supposed to be categories.BASIC + categories.ALW.

Module

payroll

Describe the bug

view to add employees is not complete in payroll processing

To Reproduce

In payroll, enter the payroll processing, create a new one and use the button to add employees
Affected versions: 16.0

Steps to reproduce the behavior:

Expected behavior

1. Enter the payroll processing
2. Create a new record
3. Use the button to add employees

Additional context

Currently accounting fields in salary rules are not company_dependent. The accounting in Salary rules should behave as Product, Product Categories, Partner, ...

Odoo (v11) has actually fixed this: odoo/odoo#28675
Related issue: odoo/odoo#23814

Global rule blacklist ban rule for next contacts

Module

payroll

Describe the bug

Rules can not appear in Paysplips depends on contract computing order.

To Reproduce

Affected versions: 13-16

Steps to reproduce the behavior:

1. Create 2 open contracts for same employee with same structure and wages 1 and 10
2. Add "C" rule to this structure with code condition: result = contract.wage > 5
3. Create Payslip for our employee without specified Contract to compute 2 added contracts in this payslip
4. Compute payslip.

Expected behavior
Payslip lines will have C rule in any cases.
But if Odoo will compute contract with wage = 1 firstly, Payslip will not contain C rule at all.
This happens cause if condition is negative Odoo adds rule to global blacklist and second contract ignores C rule at all.

IMHO We must create blacklist for every contract.

Please change to:
"code": holiday.holiday_status_id.code or "GLOBAL",

hr_payslip.py
def _get_payslip_lines(self, contract_ids, payslip_id):
I see that there is support for multiple contracts for the same payslip of an employee. So I just tried to create 2 contracts for the same employee. The second contract could not get the state running - I got an error "An employee can only have one contract at the same time. (Excluding Draft and Cancelled contracts)" So how can multiple contracts be passed to _get_payslip_lines()? What is the use case?