do not offer to change display name or password, if not possible.

[blizzz]

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 :)

[skjnldsv]

could use v-else 😉

[blizzz]

can I combine previous same v-ifs?

[skjnldsv]

Inside a template yes

<templatev-if="true">
<inputtype="text" />
<inputtype="submit" />
</template>
<divv-else />

[blizzz]

both aspects done

[johkoenig]

I really appreciate how fast you put my feature request into real code. Thumbs up for that.

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 :)

What about adding a little (i) behind the display name which, when hovering over it, says "Username generated from $Backend information"?

[blizzz]

I really appreciate how fast you put my feature request into real code. Thumbs up for that.

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 :)

What about adding a little (i) behind the display name which, when hovering over it, says "Username generated from $Backend information"?

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.

[blizzz]

Added the tooltip, updated the screenshot in the description

[johkoenig]

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 :)
Not a problem. For me, the result's the same.

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. :-)
So, I propose something like "Display name is generated from backend data"

[blizzz]

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.

[rullzer]

Code makes sense

[blizzz]

need to touch users acceptance tests yet

[blizzz]

Okay, after wondering why it failed… it just passes locally.

→ merging

I hate those CI hiccups :(