immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-02-05 08:41:28 +03:00
Code Issues 26 Packages Projects Releases 10 Wiki Activity

[BUG] Immich has separate first and last name fields and both are mandatory #1561

New Issue
Closed
opened 2026-02-05 02:21:49 +03:00 by OVERLORD · 8 comments
OVERLORD commented 2026-02-05 02:21:49 +03:00
Owner
Copy Link

Originally created by @ToxicFrog on GitHub (Nov 4, 2023).

The bug

When creating or editing a user account, you are required to provide both a first and last name. Failure to do so will not let you complete the user creation flow. If you only have one name, or a name that doesn't readily decompose into two parts, or if those parts don't map cleanly to "first" and "last", you are out of luck.

I'm not sure if this is a design bug (Immich's data model assumes that people have names that come in at least two parts called "first" and "last") or an implementation bug (Immich's data model permits freeform names but the UI is incorrectly wired up with two name fields and both are marked mandatory).

Ideally, the name field should be a single free text "display name" field. If Immich is commited to binomial names, at least one of the fields should be optional.

The OS that Immich Server is running on

docker on nixos

Version of Immich Server

v1.84.0

Version of Immich Mobile App

N/A

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

I'm not using docker-compose.yml, but a nixos config equivalent to the official docker-compose but with redis and postgres running on the host.

Your .env content

environment = {
    DB_HOSTNAME = "host.docker.inernal";
    DB_USERNAME = [redacted];
    DB_PASSWORD = [redacted];
    DB_DATABASE_NAME = "immich";

    REDIS_HOSTNAME = "host.docker.internal";
    REDIS_PASSWORD = [redacted];

    TYPESENSE_ENABLED = "true";
    TYPESENSE_HOST = "immich-typesense";
    TYPESENSE_API_KEY = [redacted];
    TYPESENSE_DATA_DIR = "/data";

    IMMICH_WEB_URL = "http://immich-web:3000";;
    IMMICH_SERVER_URL = "http://immich-server:3001";
    IMMICH_MACHINE_LEARNING_URL = "http://immich-ml:3003";
  };

Reproduction steps

  1. As an admin, click "add user".
  2. Fill in the email and password but leave one (or both) of the name fields blank.
  3. Click "create".

Additional information

Setting the last name to a single space seems to appease it and has not yet visibly broken anything.

Falsehoods Programmers Believe about Names is 13 years old at this point and still as relevant as ever.

Google dug themselves into a similar hole and it took them years to climb out of it, with ugly workarounds in the meantime like "put your actual name in the First Name field and put . in the Last Name field and it won't render the ., probably". But Google also had a lot more technical debt than Immich, so hopefully this won't take years to fix.

Originally created by @ToxicFrog on GitHub (Nov 4, 2023). ### The bug When creating or editing a user account, you are _required_ to provide both a first and last name. Failure to do so will not let you complete the user creation flow. If you only have one name, or a name that doesn't readily decompose into two parts, or if those parts don't map cleanly to "first" and "last", you are out of luck. I'm not sure if this is a design bug (Immich's data model assumes that people have names that come in at least two parts called "first" and "last") or an implementation bug (Immich's data model permits freeform names but the UI is incorrectly wired up with two name fields and both are marked mandatory). Ideally, the name field should be a single free text "display name" field. If Immich is commited to binomial names, at least one of the fields should be optional. ### The OS that Immich Server is running on docker on nixos ### Version of Immich Server v1.84.0 ### Version of Immich Mobile App N/A ### Platform with the issue - [X] Server - [X] Web - [ ] Mobile ### Your docker-compose.yml content I'm not using docker-compose.yml, but a nixos config equivalent to [the official docker-compose](https://github.com/immich-app/immich/blob/main/docker/docker-compose.yml) but with redis and postgres running on the host. ### Your .env content ```nix environment = { DB_HOSTNAME = "host.docker.inernal"; DB_USERNAME = [redacted]; DB_PASSWORD = [redacted]; DB_DATABASE_NAME = "immich"; REDIS_HOSTNAME = "host.docker.internal"; REDIS_PASSWORD = [redacted]; TYPESENSE_ENABLED = "true"; TYPESENSE_HOST = "immich-typesense"; TYPESENSE_API_KEY = [redacted]; TYPESENSE_DATA_DIR = "/data"; IMMICH_WEB_URL = "http://immich-web:3000";; IMMICH_SERVER_URL = "http://immich-server:3001"; IMMICH_MACHINE_LEARNING_URL = "http://immich-ml:3003"; }; ``` ### Reproduction steps 1. As an admin, click "add user". 2. Fill in the email and password but leave one (or both) of the name fields blank. 3. Click "create". ### Additional information Setting the last name to a single space seems to appease it and has not _yet_ visibly broken anything. [Falsehoods Programmers Believe about Names](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/) is 13 years old at this point and still as relevant as ever. Google dug themselves into a similar hole and it took them years to climb out of it, with ugly workarounds in the meantime like "put your actual name in the First Name field and put `.` in the Last Name field and it won't render the `.`, probably". But Google also had a lot more technical debt than Immich, so hopefully this won't take years to fix.
OVERLORD added the good first issue label 2026-02-05 02:21:49 +03:00
OVERLORD commented 2026-02-05 02:21:59 +03:00
Author
Owner
Copy Link

@bo0tzz commented on GitHub (Nov 5, 2023):

Thanks for the callout! There's really no reason for Immich to have separate name fields like that, so I agree that it should be changed. The name is only used for display purposes, so it should not impact anything important.

@bo0tzz commented on GitHub (Nov 5, 2023): Thanks for the callout! There's really no reason for Immich to have separate name fields like that, so I agree that it should be changed. The name is only used for display purposes, so it should not impact anything important.
OVERLORD commented 2026-02-05 02:22:01 +03:00
Author
Owner
Copy Link

@brianjaustin commented on GitHub (Nov 6, 2023):

It looks like first/last name split is encoded at the database level: a6eb227330/server/src/infra/entities/user.entity.ts (L19)

I'm thinking first, a migration that adds a name (or fullName?) field and updates that to be equal to firstName + lastName. Next, update the code to use the new field instead of first/last name. Finally, a migration to remove the 2 (now-unused) name fields. Does that sound reasonable?

@brianjaustin commented on GitHub (Nov 6, 2023): It looks like first/last name split is encoded at the database level: https://github.com/immich-app/immich/blob/a6eb22733039f4391934962a873626bafd8b45ff/server/src/infra/entities/user.entity.ts#L19 I'm thinking first, a migration that adds a `name` (or `fullName`?) field and updates that to be equal to `firstName` + `lastName`. Next, update the code to use the new field instead of first/last name. Finally, a migration to remove the 2 (now-unused) name fields. Does that sound reasonable?
OVERLORD commented 2026-02-05 02:22:08 +03:00
Author
Owner
Copy Link

@bo0tzz commented on GitHub (Nov 6, 2023):

@brianjaustin that sounds good! It doesn't need to be in discrete steps: A single PR can include both a migration to merge the two current name fields into a new name one (this should be possible just in SQL), and the new code to use that field.

@bo0tzz commented on GitHub (Nov 6, 2023): @brianjaustin that sounds good! It doesn't need to be in discrete steps: A single PR can include both a migration to merge the two current name fields into a new `name` one (this should be possible just in SQL), and the new code to use that field.
OVERLORD commented 2026-02-05 02:22:15 +03:00
Author
Owner
Copy Link

@danada commented on GitHub (Nov 6, 2023):

A single PR can include both a migration to merge the two current name fields into a new name one

I just wanted to point out that for some locales this will result in a reversed name when lastName is displayed before firstName.

Though, I'm not sure what % of the user base are using these locales (like Japanese), so it might not be worth handling this special case.

@danada commented on GitHub (Nov 6, 2023): > A single PR can include both a migration to merge the two current name fields into a new name one I just wanted to point out that for some locales this will result in a reversed name when `lastName` is displayed before `firstName`. Though, I'm not sure what % of the user base are using these locales (like Japanese), so it might not be worth handling this special case.
OVERLORD commented 2026-02-05 02:22:16 +03:00
Author
Owner
Copy Link

@jrasm91 commented on GitHub (Nov 6, 2023):

I think we already just join them in the code as first + last name. It is fine to do that in the database and the user can reverse it if needed.

@jrasm91 commented on GitHub (Nov 6, 2023): I think we already just join them in the code as first + last name. It is fine to do that in the database and the user can reverse it if needed.
OVERLORD commented 2026-02-05 02:22:20 +03:00
Author
Owner
Copy Link

@brianjaustin commented on GitHub (Nov 8, 2023):

I've been going through the places that need to be changed and found bb28cae671/web/src/lib/components/shared-components/user-avatar.svelte (L85)
In this case, what is the desired new behaviour? At the moment, I'm thinking either use the first 2 characters of the full name (discounting spaces) or try to split; possibly both, with one as a fall back

@brianjaustin commented on GitHub (Nov 8, 2023): I've been going through the places that need to be changed and found https://github.com/immich-app/immich/blob/bb28cae6712ce93dd363edd3f210dfe03253de8d/web/src/lib/components/shared-components/user-avatar.svelte#L85 In this case, what is the desired new behaviour? At the moment, I'm thinking either use the first 2 characters of the full name (discounting spaces) or try to split; possibly both, with one as a fall back
OVERLORD commented 2026-02-05 02:22:24 +03:00
Author
Owner
Copy Link

@jrasm91 commented on GitHub (Nov 8, 2023):

I think a single letter is fine for now. Gmail does this on mobile (a single letter), but also adds a color to the mix. There is another PR out there for an avatar color, so maybe once that is incorporated you could do a combination of the two. For now, just do a single letter IMO.

@jrasm91 commented on GitHub (Nov 8, 2023): I think a single letter is fine for now. Gmail does this on mobile (a single letter), but also adds a color to the mix. There is another PR out there for an avatar color, so maybe once that is incorporated you could do a combination of the two. For now, just do a single letter IMO.
OVERLORD commented 2026-02-05 02:22:27 +03:00
Author
Owner
Copy Link

@ToxicFrog commented on GitHub (Nov 19, 2023):

Thank you!

@ToxicFrog commented on GitHub (Nov 19, 2023): Thank you!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
documentation
external-library
format
good first issue
needs-answer
nice to have
sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label good first issue
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#1561
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?