-
-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[15.0][MIG] payroll #81
Conversation
It looks like there's a build problem. Probably a stale config somewhere. Can someone take a look please? |
I mean the build failures. I'll take care of the pre-commit failures. |
@nimarosa @pedrobaeza Sorry. It was my own fault for not checking the migration went properly. |
b48ecfa
to
6405d3e
Compare
@mtelahun i think contract views changed a bit in v15.0 that's why build error is about a xpath not found. |
/ocabot migration payroll |
6405d3e
to
c236735
Compare
@mtelahun Please before finishing this do a rebase with 15.0 version since i pushed updated dotfiles to have v15.0 up to date. |
Can we replace |
@norlinhenrik Hello Henrik, I think adding a dependency to a server-tools module will be bad for payroll. Most people don't download all oca repos in his instances so it will end up with an dependency error when trying to install payroll and not having the other module. I think it's good to maintain the less dependencies required here. Also, and this one is more personal, the way I see it the user who uses rule parameters expect to have the view inside payroll module. Doing this with an inherited module will be a little tricky because we need to filter all views by domain and add again the module field in base_time_parameter and think of a way to integrate it in payroll the way it's done now. In my instances I use time parameter to store specific payroll data that has to be easily changed by the user and also have some custom implementations around this model and no time to migrate them now to a new behavior or module. If you have a good way of doing this by leaving the current functionality intact you can propose a PR on the 14.0 branch and it will be migrated to 15. I'm not a fan of introducing big changes in migrations because it causes confusion and errors and will requiere migration scripts, that's why I wanted to do the big changes in 14.0 so we make modules maintenance more easy and straightforward. Hope you understand and feel free to suggest a PR if you can do it without affecting current functionality. |
358748c
to
29f9870
Compare
@nimarosa All is green now. Sorry for the noise. This was the first migration I did in a long time. During my migration I noticed that Odoo has removed the |
29f9870
to
aaac623
Compare
I think this is a separate issue and belongs in a different PR |
aaac623
to
a6d58db
Compare
Hello @mtelahun. I hate when odoo changes things like this, but I think is has to be because enterprise payroll module didn't use that code because enterprise module is different (our module is better un my opinion). What do you think about inheriting hr.leave.type here in the payroll module and adding this field again? That way we can maintain current functionality that is key for the module, at least for me. I think using name in salary rules will generate problems. If you think that adding this field to leave type will fix it we can include it in this PR. |
@mtelahun also noticed you removed all string="" of a lot of fields. Why is that? |
Yes, that's a better solution. I'll do that.
…On 14/10/2022 12:52, Nicolas Rodriguez Sande wrote:
During my migration I noticed that Odoo has removed the |code|
field from hr.leave.type. So, I have reverted the payroll module
to using the |name| instead.
Maybe, starting from 15.0 onward we need a new model to map
hr.leave.type to a code in worked days. What do you think?
Hello @mtelahun <https://github.com/mtelahun>. I hate when odoo
changes things like this, but I think is has to be because enterprise
payroll module didn't use that code because enterprise module is
different (our module is better un my opinion).
What do you think about inheriting hr.leave.type here in the payroll
module and adding this field again? That way we can maintain current
functionality that is key for the module, at least for me. I think
using name in salary rules will generate problems.
If you think that adding this field to leave type will fix it we can
include it in this PR.
—
Reply to this email directly, view it on GitHub
<#81 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4YOHGXVHIW4Y7XH3RXG4TWDEUPTANCNFSM6AAAAAAREGB4YU>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
pre-commit errors:
- string attribute on `<tree>` view is no longer allowed
- in model creation string attribute on a field that is the same as the
default string provided by the ORM are no longer allowed
…On 14/10/2022 12:59, Nicolas Rodriguez Sande wrote:
@mtelahun <https://github.com/mtelahun> also noticed you removed all
string="" of a lot of fields. Why is that?
—
Reply to this email directly, view it on GitHub
<#81 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4YOHBLGVQPY4GRGJ4X37TWDEVJFANCNFSM6AAAAAAREGB4YU>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@mtelahun yes but you are removing string in model creation not on tree view. Correct me maybe I didn't understand |
Please re-read my reply. There are two places where the `string=`
attribute raises errors.
1. in `<tree>` view
2. in model creation when the `string=` attribute is the same as the
default one provided by the ORM
…On 14/10/2022 15:28, Nicolas Rodriguez Sande wrote:
@mtelahun <https://github.com/mtelahun> yes but you are removing
string in model creation not on tree view. Correct me maybe I didn't
understand
—
Reply to this email directly, view it on GitHub
<#81 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4YOHHRVG6D64O6WXBI7E3WDFGXHANCNFSM6AAAAAAREGB4YU>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Currently translated at 100.0% (359 of 359 strings) Translation: payroll-14.0/payroll-14.0-payroll Translate-URL: https://translation.odoo-community.org/projects/payroll-14-0/payroll-14-0-payroll/es_AR/
996c6b0
to
b3970c1
Compare
@nimarosa @apps2grow Please review and let's merge. This incorporates the latest changes. |
@mtelahun for me it's okay. Just done a code review and commit history looks okay. Did you tested it yet? Like functional. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I successfully computed a payslip for Marc Demo.
This PR has the |
Okay let's go. I have a few PRs that I might add to 14.0 but we can migrate them later. /ocabot merge nobump |
This PR looks fantastic, let's merge it! |
@nimarosa The merge process could not be finalized, because command
|
Congratulations, your PR was merged at 1621285. Thanks a lot for contributing to OCA. ❤️ |
@nimarosa Yes, I tested it. Thanks for merging.
Mike.
…On 11/11/2022 01:31, Nicolas Rodriguez Sande wrote:
Okay let's go.
I have a few PRs that I might add to 14.0 but we can migrate them later.
/ocabot merge nobump
—
Reply to this email directly, view it on GitHub
<#81 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4YOHCMPD2LPCSOLNZUJR3WHVZV7ANCNFSM6AAAAAAREGB4YU>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Fixes: #19
cc: #78