starred/lldap-lldap

Fork 0

mirror of https://github.com/lldap/lldap.git synced 2026-04-26 00:36:01 +03:00

[GH-ISSUE #474] User creation requires firstname, lastname #178

New issue

Closed

opened 2026-02-27 08:15:42 +03:00 by kerem · 7 comments

kerem commented

2026-02-27 08:15:42 +03:00

Owner

Originally created by @tetricky on GitHub (Mar 16, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/474

I have recently updated to 0.4.1.

At some point it seems that creating a new user has gone from requiring uid, email, and display name, to also requiring first name and last name.

I can't see any notice of this change, is it intended?

for my own use case first name and last name are not used....I only require username and email from my users. (I am happy to add username as display name as well, as that allows for the possibility to change at a later date).

It is also not possible to delete firstname or lastname after user creation:

Errors: [updateUser:2:3: Database error: `Execution Error: error returned from database: (code: 1299) NOT NULL constraint failed: users.first_name`]

A consequence of this, for my use case, is that I am currently copying the user id into three other settings, in order to create a user (sub-optimal)...and am concerned that the absence of these fields in previously created users will cause other spin off problems (some users are reporting seeing some problems logging into their profile, and I'm concerned that this may be the reason).

Originally created by @tetricky on GitHub (Mar 16, 2023). Original GitHub issue: https://github.com/lldap/lldap/issues/474 I have recently updated to 0.4.1. At some point it seems that creating a new user has gone from requiring uid, email, and display name, to also requiring first name and last name. I can't see any notice of this change, is it intended? for my own use case first name and last name are not used....I only require username and email from my users. (I am happy to add username as display name as well, as that allows for the possibility to change at a later date). It is also not possible to delete firstname or lastname after user creation: ``` Errors: [updateUser:2:3: Database error: `Execution Error: error returned from database: (code: 1299) NOT NULL constraint failed: users.first_name`] ``` A consequence of this, for my use case, is that I am currently copying the user id into three other settings, in order to create a user (sub-optimal)...and am concerned that the absence of these fields in previously created users will cause other spin off problems (some users are reporting seeing some problems logging into their profile, and I'm concerned that this may be the reason).

kerem

2026-02-27 08:15:42 +03:00

closed this issue
added the
bug

backend
labels

kerem commented

2026-02-27 08:15:43 +03:00

Author

Owner

@nitnelave commented on GitHub (Mar 16, 2023):

I think that was a temporary problem for the release 0.4.1, that was fixed soon after (but not released because I'm a bit lazy in terms of releases). You can update to latest, that should solve the problem.

@nitnelave commented on GitHub (Mar 16, 2023): I think that was a temporary problem for the release 0.4.1, that was fixed soon after (but not released because I'm a bit lazy in terms of releases). You can update to `latest`, that should solve the problem.

kerem commented

2026-02-27 08:15:43 +03:00

Author

Owner

@tetricky commented on GitHub (Mar 16, 2023):

...my process is to keep the release image, tagged with the version number, and copy it to localhost with a latest tag when I want to deploy it. That way I can keep track of what my current version is, and apply any updates when they arise (and also roll back if necessary/possible). It also means I can check the code of the deployed version.

What version is the current latest? Even if it's not a stable release, if I knew it was (say) 0.4.2-beta, it would at least have some context in terms of versioning.

@tetricky commented on GitHub (Mar 16, 2023): ...my process is to keep the release image, tagged with the version number, and copy it to localhost with a latest tag when I want to deploy it. That way I can keep track of what my current version is, and apply any updates when they arise (and also roll back if necessary/possible). It also means I can check the code of the deployed version. What version is the current latest? Even if it's not a stable release, if I knew it was (say) 0.4.2-beta, it would at least have some context in terms of versioning.

kerem commented

2026-02-27 08:15:43 +03:00

Author

Owner

@tetricky commented on GitHub (Mar 17, 2023):

I've pulled the latest alpine image, and found that is what I am already using in my setup.

So this behaviour is one that I am seeing with the current image.

@tetricky commented on GitHub (Mar 17, 2023): I've pulled the latest alpine image, and found that is what I am already using in my setup. So this behaviour is one that I am seeing with the current image.

kerem commented

2026-02-27 08:15:43 +03:00

Author

Owner

@nitnelave commented on GitHub (Mar 17, 2023):

oh, I see what happened. Yeah, it's due to a transitive state at the 0.4.1 update. I'll have to do a bit more schema contortions to fix it, but it shouldn't be too hard. We had some similar problem with the display name.

FWIW, what you can do is to backup the DB (without schema), restart LLDAP to recreate it, stop LLDAP, restore the DB contents and it should work.

@nitnelave commented on GitHub (Mar 17, 2023): oh, I see what happened. Yeah, it's due to a transitive state at the 0.4.1 update. I'll have to do a bit more schema contortions to fix it, but it shouldn't be too hard. We had some similar problem with the display name. FWIW, what you can do is to backup the DB (without schema), restart LLDAP to recreate it, stop LLDAP, restore the DB contents and it should work.

kerem commented

2026-02-27 08:15:43 +03:00

Author

Owner

@tetricky commented on GitHub (Mar 18, 2023):

That's problematic in my setup (and with my knowledge). Will a future update likely correct this? If so I'll stay with my workaround for a bit.

@tetricky commented on GitHub (Mar 18, 2023): That's problematic in my setup (and with my knowledge). Will a future update likely correct this? If so I'll stay with my workaround for a bit.

kerem commented

2026-02-27 08:15:43 +03:00

Author

Owner

@nitnelave commented on GitHub (Mar 19, 2023):

Yes, I'll try to get it fixed before the next release (otherwise it'll break for many people)

@nitnelave commented on GitHub (Mar 19, 2023): Yes, I'll try to get it fixed before the next release (otherwise it'll break for many people)

kerem commented

2026-02-27 08:15:43 +03:00

Author

Owner

@tetricky commented on GitHub (Mar 21, 2023):

I've upgraded to latest, and can confirm this issue is now resolved.

Thank you very much!

@tetricky commented on GitHub (Mar 21, 2023): I've upgraded to latest, and can confirm this issue is now resolved. Thank you very much!

kerem referenced this issue

2026-02-27 08:18:06 +03:00

[PR #178] [MERGED] Add Matrix example config #593