Skip to content
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

[4548][IMP] l10n_jp_hr_employee, hr_employee_nrq, hr_employee_qualifications: change char to many2one for qualification name field #268

Merged
merged 30 commits into from
Jun 20, 2024

Conversation

AungKoKoLin1997
Copy link
Contributor

@AungKoKoLin1997 AungKoKoLin1997 commented May 13, 2024

4548
Depends on qrtl/nrq-oca#13

@AungKoKoLin1997 AungKoKoLin1997 changed the title [4548][IMP] change char to many2one for qualification name field [4548][IMP] l10n_jp_hr_employee: change char to many2one for qualification name field May 13, 2024
<field name="model">qualification.name</field>
<field name="arch" type="xml">
<tree editable="top">
<field name="name" />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please add the sequence handle?



class QualificationName(models.Model):
_name = "qualification.name"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find it a bit strange as a model name. How about hr.qualification or just qualification?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

name field is exist in hr.qualification model and this model will have different type of qualifications. So I decided to use hr.qualification.type.

Copy link
Member

@yostashiro yostashiro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kanda999 Please check the validity of my suggestions.

Comment on lines 26 to 27
is_allowed_score = fields.Boolean(related="name.is_allowed_score", store=True)
score = fields.Char()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

score makes the scope of the field too narrow. Let's allow more flexibility.

Suggested change
is_allowed_score = fields.Boolean(related="name.is_allowed_score", store=True)
score = fields.Char()
qualification_type_id = fields.Many2one("hr.qualification.type", required=True, string="Qualification Type")
needs_description = fields.Boolean(related="qualification_type_id.needs_description")
description = fields.Char()

No need to store needs_description.

@@ -15,14 +15,36 @@ class HrQualification(models.Model):
_name = "hr.qualification"
_order = "date_obtained"

name = fields.Char(required=True, help="e.g. CISA",)
name = fields.Many2one("hr.qualification.type", required=True)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
name = fields.Many2one("hr.qualification.type", required=True)
name = fields.Char(compute="_compute_name", store=True)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can get rid of the extensions of name_get() and name_search() this way.

Comment on lines 30 to 32
parent="hr.menu_hr_root"
sequence="4"
groups="base.group_user"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
parent="hr.menu_hr_root"
sequence="4"
groups="base.group_user"
parent="hr.menu_human_resources_configuration"
sequence="10"


name = fields.Char(required=True, help="e.g. CISA")
sequence = fields.Integer(default=10)
needs_description = fields.Boolean(help="If enabled, allows input in the description field of the qualification.")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
needs_description = fields.Boolean(help="If enabled, allows input in the description field of the qualification.")
needs_description = fields.Boolean(help="If enabled, description field of the qualification becomes required.")

@@ -12,6 +12,7 @@
<field name="res_model">hr.private.info</field>
<field name="view_type">form</field>
<field name="view_mode">tree,form</field>
<field name="context">{'readonly_by_pass': True}</field>
Copy link
Member

@yostashiro yostashiro May 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we use this, we should add web_readonly_bypass as a dependency in the manifest file.

The question is, is it really worth adding the new module just for _onchange_qualification_name() (we should change the method name according to the field name, by the way, if we are to keep this method)?

Another approach is to just extend create() and write() and clear description when qualification_type_id is in vals and qualification_type_id.needs_description is false, instead of using the onchange method. I personally think this approach would be acceptable (the description value doesn't need to be cleared on the fly when qualification type is changed).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think your idea is better because it can reduce the maintenance cost and simple.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using create(), write() and onchange funcs still have some unexpected behavior. So, I decided to use onchange with the help of web_readonly_bypass.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AungKoKoLin1997 OK, thanks for the persistence!

Copy link
Member

@yostashiro yostashiro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review.

@kanda999 kanda999 force-pushed the 10.0-imp-l10n_jp_hr_employee branch from 05f9c26 to a6099b2 Compare May 27, 2024 07:25
Copy link
Contributor

@kanda999 kanda999 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code and Functional review.

@kanda999 kanda999 force-pushed the 10.0-imp-l10n_jp_hr_employee branch from 4429b00 to b641e83 Compare June 5, 2024 09:38
Comment on lines 101 to 121
recom_qualification_ids = fields.One2many(
"hr.qualification",
"private_info_id",
string="Qualification",
string="Recommended Qualification",
context={"active_test": False},
domain=[('qualification_category','=','recommended')]
)
non_recom_qualification_ids = fields.One2many(
"hr.qualification",
"private_info_id",
string="Non Recommended Qualification",
context={"active_test": False},
domain=[('qualification_category','=','non_recommended')]
)
lang_qualification_ids = fields.One2many(
"hr.qualification",
"private_info_id",
string="Language Qualification",
context={"active_test": False},
domain=[('qualification_category','=','language')]
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My preference is to make these fields non-stored compute fields, like we did with capture_line_filtered_ids in project_task_capture, and keep the original qualification_ids as is, unless there is a technical limitation with this implementation for conceptual robustness. What makes me a bit uncomfortable with the current design is that these fields are added with dedicated table relations while they are needed merely for presentation purpose. But I might be overthinking...

Copy link
Member

@yostashiro yostashiro Jun 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please disregard my previous comment; I think the current implementation is valid as having those xxx_qualification_ids fields doesn't affect the database structure.

@kanda999 kanda999 changed the title [4548][IMP] l10n_jp_hr_employee: change char to many2one for qualification name field [4548][IMP] l10n_jp_hr_employee, hr_employee_nrq, hr_employee_qualifications: change char to many2one for qualification name field Jun 20, 2024
@kanda999 kanda999 merged commit b4872cf into 10.0 Jun 20, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants