Merge of hr_payroll_cancel and hr_payroll_change_state. about payroll HOT 14 CLOSED

from payroll.

I consider the cancel option a base feature.

from payroll.

from payroll.

MIchael, take into account that anyone may make any mistake. and not being able to amend it is not good IMO.

from payroll.

from payroll.

Thanks for bringing such concerns. I think we can just protect that feature under a configuration option "Enable payslip cancelling" or similar, so that only system administrators can modify this and if disabled, payroll managers won't be able to do it although the feature is integrated. What do you think?

from payroll.

Hello, I agree with @pedrobaeza that we could protect the feature. Maybe a setting it's not necessary: we can work in improving the user security groups and make more roles with restrictive permissions, or add this feature security group in a checkbox in user settings (security) like some other modules do, it could be "Allow to cancel payslips" checkbox.

Also @mtelahun pointed to a case when you automated payroll and want the users to only work in the system. But we can make the cancellation process something an administrator can approve. Also with current security groups the user with the fewer payroll rights can edit anything in the payslip, which is not recommended for an automated payroll, that's other reason to work in improving security groups.

Also I want to vote for also merge the change_state wizard to the base module. As I see it, it's a basic function the user would expect: if the business has like 100 payslips per payroll process, the user will expect to select all and approve all of them. With the current behavior the user will have to enter each payslip to approve it and the follow to the next one. In a large payroll this will be expected. Also if you guys don't want to merge change_state to the base module we can work in at least having buttons in tree view to deal with the approval.

What you think?

from payroll.

I prefer a setting to unlock the feature, as other group or other validation mechanisms will make this more convoluted with no reason. With this setting, Michael's concern - which were legitimate - are attended, so let's not invent more use cases until they are needed by our real users.

from payroll.

@pedrobaeza Great so a setting will be. I can start working on it and propose a PR with the feature.

What about the change_state module?

@appstogrow any opinion about this?

from payroll.

Hello,
+1 for Settings instead user or groups.

+1 for include Change status in module.

from payroll.

Hello,
+1 for Settings instead user or groups.

+1 for include Change status in module.

I agree

from payroll.

@mtelahun If "hr_payroll_change_state" is merged into "payroll", will you then have to remove the feature for your client? If so, would you like "payroll" to have another option in settings to turn on/off the feature?

from payroll.

Closed since #63 and #64 integrates this changes.

from payroll.

from payroll.