do not offer to change display name or password, if not possible. #12335
Conversation
| :disabled="loading.displayName||loading.all" | ||
| :value="user.displayname" ref="displayName" | ||
| autocomplete="new-password" autocorrect="off" autocapitalize="off" spellcheck="false" /> | ||
| <input type="submit" class="icon-confirm" value="" /> | ||
| <input v-if="user.backendCapabilities.setDisplayName" type="submit" class="icon-confirm" value="" /> | ||
| <div v-if="!user.backendCapabilities.setDisplayName" class="name">{{user.displayname}}</div> |
There was a problem hiding this comment.
can I combine previous same v-ifs?
There was a problem hiding this comment.
Inside a template yes
<template v-if="true">
<input type="text" />
<input type="submit" />
</template>
<div v-else />
|
I really appreciate how fast you put my feature request into real code. Thumbs up for that.
What about adding a little (i) behind the display name which, when hovering over it, says "Username generated from $Backend information"? |
tbh, I think it is a long standing issue, just could not find the original bug report. Might be well from before-fork-times :D I was curious to see whether I could bake this in into the new frontend code for users management :)
A valid for statement LDAP, hypothetically not for other possible backends. But perhaps a tooltip that states that the values cannot be changed against the backend would suffice I guess. |
Fixes #12319 Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
blizzz
force-pushed
the
fix/12319/respect-fixed-usernames
branch
from
5b72d15
to
505722c
Compare
|
Added the tooltip, updated the screenshot in the description |
blizzz
added
3. to review
By the way, your current wording "The backend does not support changing the display name" is a little bit misleading. Despite what you say, the display name can be changed. The point is, it must be done in the backend. :-) |
My intention is to refer to the backend in Nextcloud context, but you can argue it's a connector to the backend service. I had the same thoughts, but did not see it as much of a problem. |
|
need to touch users acceptance tests yet |
|
Okay, after wondering why it failed… it just passes locally.
→ merging I hate those CI hiccups :( |
Fixes #12319
That's more a quick prototype, tests might fail, did not look for them.
Question: can we just extend the OCS endpoint with those additional data? In fact, it it could be more compact with the backend data as different result sets and users just pointing to the related backend feature set …
Also, it does not look very consistent. There should be an indicator whether a display name is editable or not, but that should not vary too much. That's something for CSS magicians howerver :)