[GH-ISSUE #387] Cannot create user without a Display Name but there is no validation in frontend #150

New issue

Closed

opened 2026-02-27 08:15:32 +03:00 by kerem · 1 comment

kerem commented

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

Owner

Originally created by @Moovlin on GitHub (Dec 1, 2022).
Original GitHub issue: https://github.com/lldap/lldap/issues/387

It seems that there is a change in requirement where the display name for a new user must be included. Based on the front end, this seems to be a non required field which in turns causes an error on the back end.

I'm under the impression that this should be optional and was in previous versions but with the change of the ORM, this seems to have caused a constraint issue. If I compare this to a field which is marked as required, it seems the front end does that validation before I am able to submit the form.

Due to this difference, I think the regression lies in the model but if it makes more sense to require a display name that works for me as well. I would be happy to work on this. As a side thought, this issue, along with the other related issue related to the switch to the ORM, may be fuel for a discussion of adding unit tests but that discussion is likely out of scope for this issue.

Originally created by @Moovlin on GitHub (Dec 1, 2022). Original GitHub issue: https://github.com/lldap/lldap/issues/387 It seems that there is a change in requirement where the display name for a new user must be included. Based on the front end, this seems to be a non required field which in turns causes an error on the back end. ![2022-12-01-142500_1084x643_scrot](https://user-images.githubusercontent.com/1934731/205142165-b2c3a5c4-eedb-477d-b7d1-056b00943e89.png) I'm under the impression that this _should_ be optional and was in previous versions but with the change of the ORM, this seems to have caused a constraint issue. If I compare this to a field which is marked as required, it seems the front end does that validation before I am able to submit the form. ![2022-12-01-142846_1062x646_scrot](https://user-images.githubusercontent.com/1934731/205142598-af99ae8f-94c7-4076-88ee-4172ad42dc72.png) Due to this difference, I think the regression lies in the model but if it makes more sense to require a display name that works for me as well. I would be happy to work on this. As a side thought, this issue, along with the other related issue related to the switch to the ORM, may be fuel for a discussion of adding unit tests but that discussion is likely out of scope for this issue.

kerem

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

closed this issue
added the
bug

good first issue

frontend

backend
labels

kerem commented

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

Author

Owner

@Moovlin commented on GitHub (Dec 1, 2022):

Since I offered to work on this, I figured it'd be best to quickly summarize the conversation I had with @nitnelave on Discord.
The process towards resolution will roughly be as follows:

Revert to the old schema, this should really only effect a hand full of users like myself who created instances in the last week or so.
Create a new type within the types.rs file for the display_name field in the User struct to allow for us to leverage the ORM to handle the conversion from None <-> "". UserId is an example of such a type.
Build a quick SQL command to remediate schema differences for users who created their DBs where this issue is present.

@Moovlin commented on GitHub (Dec 1, 2022): Since I offered to work on this, I figured it'd be best to quickly summarize the conversation I had with @nitnelave on Discord. The process towards resolution will roughly be as follows: 1) Revert to the old schema, this should really only effect a hand full of users like myself who created instances in the last week or so. 2) Create a new type within the `types.rs` file for the `display_name` field in the `User` struct to allow for us to leverage the ORM to handle the conversion from `None` <-> `""`. `UserId` is an example of such a type. 3) Build a quick SQL command to remediate schema differences for users who created their DBs where this issue is present.

kerem referenced this issue

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

[PR #150] [MERGED] readme: Make compatible services more explicit #573