Option: Benutzerdefinierte Felder auf Eindeutigkeit prüfen

[nomisge]

Bei den benutzerdefinierten Felder wäre es gut, wenn diese so konfiguriert werden können, dass bei Wertzuweisung in das benutzerdefinierte Feld (z.B. bei Listenimport, oder Änderung durch Nutzer selbst) geprüft wird, ob der Wert bereits von einem anderen Nutzer belegt ist. Sollte der Wert nicht eindeutig sein, wird ein Fehler zurück gegeben und zur Eingabe eines eindeutigen Wertes aufgefordert.

Die Eindeutigkeitsprüfung soll zudem konfigurierbar sein über welche Rollen Eindeutigkeit sichergestellt werden muss.

Die UI könnte folgendermaßen erweitert werden:

Anwendung: An einer Schule authentifiziert ein externer Dienst (z.B. Moodle) gegen die LMN und zieht zudem Nutzerdaten via LDAP. Die Emailadresse aller Nutzer (sowohl Lehrer, als auch Schüler) muss in diesem Dienst eindeutig sein. Nutzer sollen Ihre Mailadresse (nicht die lokal generierte, sondern eines beliebigen Providers) in der Schulkonsole selbst bearbeiten können. Dabei muss sichergestellt werden, dass keine zwei Nutzer die gleiche Mailadresse eingeben.

[kiarn]

Hello @nomisge

It's a common practice to speak english, so I will answer in english, but we can follow the discussion in discourse in german if you want ;)

I see your point and fully understand the request, but I see a problem in the workflow : if an user changes his data, there's no possibility to test it against the data of the other users, this is blocked by design. Only the admins have this feature and it's not a good idea to change this, for security reason.

I only sse the following solutions :

• implement this in the backend, sophomorix, then it is an issue for sophomorix when sophomorix-user is invoked,
• periodic checks using a cronjob, means that a change will not be tested at user input,
• manually check as admin, involving the same problem as the periodic checks.

For each of this solution it's also necessary to have enough parameters or configuration possibilities.

There's also a solution to configure a ldap field as unique, but it's pretty complicated.

Arnaud

[nomisge]

HI @kiarn, Don't worry english is fine. I figured it would be better to write in english, just after I posted the feature request. Didn't have time to change it into english. Should I?

I was told, that user custom fields are set directly from the webui, without any sophomorix scripts beeing run. Thus I figured here is the right place to request the feature.

The security aspect is a valid reason and by what you wrote I think the sophomorix path would be the cleanest of the suggested solutions, if fields are changed in user context. If changed in admin context it could be done directly, but two different paths don't seem wise?

Let us know, if this feature could be realized any time soon (e.g. within the next year).

Thx, Simon

[kiarn]

Hi @nomisge,

Didn't have time to change it into english. Should I?

I don't think it's necessary.

The security aspect is a valid reason and by what you wrote I think the sophomorix path would be the cleanest of the suggested solutions, if fields are changed in user context. If changed in admin context it could be done directly, but two different paths don't seem wise?

I also think it's better to ask about an common implementation on the sophomorix side, it would be a more proper way to achieve tihs feature.

It could be some new parameter like :

sophomorix-user -u USER --custom1 --uniq students,teachers

I opened an issue there : https://github.com/linuxmuster/sophomorix4/issues/161

Let us know, if this feature could be realized any time soon (e.g. within the next year).

This is a question to ask at @jeffbeck, the developer of sophomorix, I cannot tell. But even if it's done in sophomorix, I will have to adapt the code in the Webui :

• handle configuration as you wrote in your first post,
• add the new parameters in sophomorix calls, relative to the configuration.

Cheers

Arnaud

[jeffbeck]

In following answer it is said that uniqueness is not part of the scheme, so we cannot enforce it by means of AD:

https://stackoverflow.com/questions/50502779/determine-if-ldap-attribute-must-be-unique-value-across-the-entire-domain

The only way to implement it is by the programms that use the attribute.

I'm not sure if that is a good idea anyway foa custom field: 1) Because this would mean something like 'first (wrong) entry wins', and can Block other (correct) entries. 2) Other way around: I can think of useful double email adresses (i.e. I have 2 accounts on our server, one to test the other to work).

[jeffbeck]

see: https://github.com/linuxmuster/sophomorix4/issues/161