Open etopipec opened 1 week ago
I will study the issue of custom fields and will definitely come back
I found two tables. If I understood you correctly, we need to add a new record to person_custom_master
, and add a new column to person_custom
. If I'm wrong, please correct me.
I would like to understand why we can do it via custom fields
If we want to add a db field I'm ok with it but we need to regen the orm and do a few more things
@DawoudIO This is your project, but I disagree with the idea of custom/dynamic properties, especially for common fields.
In general, dynamic columns in SQL is generally a bad idea for these reasons:
I'm inclined to agree with @DawoudIO on this one; a "nickname" field (or any other arbitrary attribute) can be added by the admin via leveraging custom fields, without us needing to make code changes. Sure, dynamic database stuff introduces some complexity with schema changes (as @DAcodedBEAT pointed out) but I believe this is the lesser of the two evils.
Historically, when support requests have come through for random fields to be added to person/family pages the discussion is usually that whatever the requested attribute is, represents a corner case very few people would actually want or need it. In which case, the custom field feature still allows the admin to create whatever they like and the world keeps spinning.
The next phase of the discussion inevitably centres around being able to "hide" arbitrary fields that admins may not want to see. Deleting them isn't really an option because they are part of the schema etc, but we could simply hide them from the UI. However the current code base has no way to do this (yet) although it would be an interesting project.
Personally, I have no use for a "nickname" field, and would loath having to look at another empty field on an already busy page.
My $0.02 worth 👍🏻
I'm inclined to agree with @DawoudIO on this one; a "nickname" field (or any other arbitrary attribute) can be added by the admin via leveraging custom fields, without us needing to make code changes. Sure, dynamic database stuff introduces some complexity with schema changes (as @DAcodedBEAT pointed out) but I believe this is the lesser of the two evils.
Historically, when support requests have come through for random fields to be added to person/family pages the discussion is usually that whatever the requested attribute is, represents a corner case very few people would actually want or need it. In which case, the custom field feature still allows the admin to create whatever they like and the world keeps spinning.
The next phase of the discussion inevitably centres around being able to "hide" arbitrary fields that admins may not want to see. Deleting them isn't really an option because they are part of the schema etc, but we could simply hide them from the UI. However the current code base has no way to do this (yet) although it would be an interesting project.
Personally, I have no use for a "nickname" field, and would loath having to look at another empty field on an already busy page.
My $0.02 worth 👍🏻
@MrClever I see your point about avoiding clutter, but:
As a base user property, this would provide consistency across deployments and improve personalization for users who prefer being addressed informally, while keeping it optional for those who don’t need it. It simplifies maintenance by avoiding custom fields and gives flexibility to scale with user needs in the future.
Description & Issue number it closes
Nickname field added. https://github.com/ChurchCRM/CRM/issues/6651
Screenshots (if appropriate)
![20241014_19h56m20s_grim](https://github.com/user-attachments/assets/38da9b43-31d2-4ce5-880e-50140fb512cd) ## How to test the changes? Visual inspection. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update # How Has This Been Tested? Visual inspection. Creating, editing person. Adding nickname.