feature: nickname field added

[etopipec]

Description & Issue number it closes

Nickname field added.
#6651

Screenshots (if appropriate)

How to test the changes?

Visual inspection.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• 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.

[DawoudIO]

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

[etopipec]

I will study the issue of custom fields and will definitely come back

[etopipec]

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.

[DAcodedBEAT]

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:

1. Schema Inconsistency: While the app may not change often, having different columns across deployments makes it harder to maintain consistency. It increases the risk of errors when deploying updates or running queries across environments.
2. Difficult to Scale: If you ever need to scale the app or share the database across different instances (I.e. the ability to support multiple churches), managing variable schemas becomes much more complicated.
3. Maintenance Overhead: Even if columns don’t change frequently, tracking which deployment uses which schema creates additional maintenance work. Debugging or updating the app gets harder over time.
4. Upgrade Challenges: When deploying new versions or updates, migrations and schema changes can become unpredictable, making rollouts riskier and harder to automate.

[MrClever]

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 👍🏻

[DAcodedBEAT]

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:

1. there is already a lot of unnecessary clutter all across this database schema
2. the custom fields contributes to this clutter and
3. since non-official names (like nicknames, given names vs legal/government names, etc) are very common, especially in community-oriented systems like church management software, they could be valuable as a base user property.

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.