Have superadmin and guest settings configurable

Development
#1

Hi devs,

Currently we hardcode the settings for guest and superadmin (e.g. the default editor, whether the user is advanced or not, whether the user sees hidden docs, the display name, etc).

For example in https://jira.xwiki.org/browse/XWIKI-17104 I proposed to have the default editor for superadmin be the text editor because I thought that superadmin is a technical user who should have all the power and the text editor is the lowest denominator (the wysiwyg editor might not even exist in a given flavor). But I can imagine some users wanting that their superadmin user have the wysiwyg editor set by default.

So my proposal is to introduce config options in xwiki.properties for these special users:

user.superadmin.<property key>=<value>
user.guest.<property key>=<value>

Example:

user.superadmin.editor=Wysiwyg
user.guest.showHiddenDocuments=1

WDYT?

Thanks

#2

Sounds good.

I’d personally even group them all under user.preferences.<userName>.<propertyKey>=<value>, to keep the user namespace clean for future additions.

#3

Sounds good to me. I was also wondering about this. Your proposal seems more safe for the future.

#4

+1

+1

#5

+1 on both same as Thomas.

#6

the wysiwyg editor might not even exist in a given flavor

Note that this doesn’t need to be the concern of the code that handles the default for the superadmin, the default value can be “unset”, which means that it would inherit whatever wiki-wide preference is set (in XWikiPreferences), just like for any other user that hasn’t specifically set that preference in their profile.

This being said, don’t forget to include the possibility to set this property as “unset” when planning the values that these configs can take.

It can also be interesting to be able to set these options for the superadmin without restarting the instance, but since activating superadmin requires a restart anyway, it would be just a matter of comfort to be able to change them from XWikiPreferences.

#7

@lucaa I’m not expecting this to be used much. This is really pushing the limit and offering some extra configuration option in the rare case when this can be needed. We haven’t really needed this for 16 years. Thus I’m going to only implement configuration from xwiki.properties for now . We can also improve later on and decide if that can be configurable from some wiki source. But I’m really not fond of this, especially since one important goal of this new User API is to make it independent of the user store implementation and right now the SuperAdmin and Guest users are independent of any store implementation already. Getting their data from a wiki source would break that. It’s possible to do it but I’d rather not (at least for now).

Hope it’s ok. Thanks

#8

It’s now implemented and documented at https://extensions.xwiki.org/xwiki/bin/view/Extension/User%20Module/API/#HConfiguration

#9

I don’t agree to have the default value of the editor set to “text” for the superadmin if there is no way to set that to “unset” and have the behaviour for superadmin similar to any other user that hasn’t set that property explicit in their profile.
As far as I understood, this is not possible with the current settings, the value can be only “text” or “wysiwyg”.
If it’s possible to unset this for superadmin, I don’t really care that much about the default.

#10

the reason for being interested in this setting for superadmin is that the default editor is actually changing elements of the behaviour of the wiki for a user.
Hidden documents and advanced user are thought as additional things that are visible or not for a user (advanced user - menu & some things in the create screen, hidden documents - extra documents that are visible on navigation) while the default editor is actually impacting all the inline form screens, document edit screens, etc, with no possibility to see the alternative (the version that uses the default settings of the wiki). In the case of hidden documents and advanced user options, if the user knows what those 2 settings are controlling, the user only needs to imagine the screen without some options / elements.
While the editor is an option that a user can set in their profile (just like advanced and hidden), it should be possible to be able to configure that as “inherit from default” for the superadmin, so that superadmin experiences the same UI as a regular user that hasn’t set this.

#11

Actually, after more thinking, it’s easy to do. All we need is to introduce a new EditorType enum of UNDEFINED or UNKNOWN (and ofc modify where it’s used, right now, the untyped user api is used there but this should be changed to use the new typed in the future).

So it goes back to choosing what the default value for the editor should be for superadmin. There are 3 choices:

  • Text
  • Wysiwyg
  • UNDEFINED
#12

@tmortagne, @surli, @Enygma in my original proposal I proposed using “Text” for the default superadmin editor and you agreed about it (hence you’re +1). Can you confirm if that would still be your preferred choice even if we had a UNDEFINED option for the editor (in this case it would default to the wiki default which would be Wysiwyg by default, meaning that if you wanted the Text editor for superadmin you’d need to override it in xwiki.properties).

Thanks

#13

Note that, after reading Anca’s point and double checking my previous explanation for the vote (on chat), I would say that I agree with Anca.

Of course. If you ask me, the object editor should always display text mode for textAreas, since if you are there, it’s because you’re doing under the hood changes and are supposed to know what you are doing. The wysiwyg usually is slow to load and gets in the way of your quick fix. Even if you do switch to the source tab, it wastes a lot of space and it’s also quite crammed up in the small space available to the textarea by default. Anyway, you get my point :slight_smile:

What I realized was that I only read it as the default editor for superadmin *in object mode*.

  • When it comes to inline edit, or even UIs in view mode, it makes little sense to break the UI of the app for superadmin users viewing it (note: not object editing it) and, consequently, breaking the behavior we’ve had since the start of the project. (yes, this would be a behavior change which could also break some automated UI tests, in theory)
  • When it comes to the object editor, as mentioned, the wysiwyg gets in the way even for regular users, so I would prefer it to be text, at least for superadmin, a user that really needs control. Don’t confuse this control with inline editors/UI above.

As for “unsetting” it, in practice, it should be a matter of not adding (or removing if present) the line in xwiki.properties, which should make the resolution revert to what we already do today, when the superadmin document does not exist and we use a default (either hardcoded or resolved from the Users class).

#14

Note that technically I also know how to be able to support the unset use case (simply by defining an empty property in xwiki.properties).

#15

It doesn’t break it :slight_smile:

Here’s a screenshot of click on Edit on a page with a form:

Screenshot 2020-03-10 at 13.01.44
Screenshot 2020-03-10 at 13.01.442884×1686 299 KB

What it changes is the editor to be used when editing text but you’re still in inline edit.

#16

Sure, but it’s not really justified. The superadmin user could be used for “lighter” operations as well, and you don’t have to “make life hard” for the person using it to check something or correct a small issue.

If you want an answer, then the backwards compatible answer would be to use wysiwyg by default.

To me, the only case where your proposal made sense was the object editor. That’s the only place where you go in under all the “sheets” and “UIs” and have to manually fix something, so you need control. Other than that, I see no reason to change the current behavior.

#17

FTR my original rationale for superadmin user having the text editor by default was:

  • Superadmin is a technical user. The most technical one actually. Thus it makes sense to provide the technical editor for it.
  • The wiki editor allows to do everything and without risking mistakes. When using the WYSIWYG ones, it’s easy to make mistakes and break things when you edit technical content (extra new lines, conversions, etc). The text editor is not easier to use for making tech changes but it’s also safer.
  • The superadmin user is off by default and is a user that’s not supposed to be used except when you broke your permissions in your system and you need to change them back. It’s definitely not a user that you should use to edit pure content. It should only be there to edit technical content and the text editor is the best editor for technical content.
#18

It’s not about make the life harder it’s about making it easier! :slight_smile: When you need to make technical changes (and that’s the only valid reason to use the superadmin user) then the wiki editor is the best choice. I would never dream of editing technical content using the WYSIWYG editor…

More generally see my reasons for proposing the text editor here: https://forum.xwiki.org/t/have-superadmin-and-guest-settings-configurable/6436/17?u=vmassol

#19

If you’re using the superadmin user as a way to log in without having to create an account, then I believe it’s very very wrong. It’s very dangerous since you have all permissions and you can easily break everything, it’s also not traceable since you don’t know who made changes.

And yes if we can make it harder to use the superadmin user then all the best because it’s not meant to be used!

#20

I don’t agree with that, since you might have limitations that prevent you from creating users for each person that needs to perform an intervention (or even a simple check) on a wiki. The superadmin user is perfect for this (has all the needed rights and is available OOB).

Of course, the perfect solution would be superadmin + impersonation feature that would allow a superadmin to see exactly what another user is seeing (if you need to reproduce a reported problem, etc.), but we are not there yet.