It’s now implemented and documented at https://extensions.xwiki.org/xwiki/bin/view/Extension/User%20Module/API/#HConfiguration
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.
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.
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
@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
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
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).
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).
It doesn’t break it 
Here’s a screenshot of click on Edit on a page with a form:
What it changes is the editor to be used when editing text but you’re still in inline edit.
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.
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.
It’s not about make the life harder it’s about making it easier! 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
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!
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.
It’s definitely not perfect and very wrong to use superadmin for that. I mentioned why above but I’ll repeat it with more details:
- It’s dangerous, very dangerous and if all you need is to change a typo or some content, it’s just plain stupid. You should only use the superadmin user if you need the power (ie if you need the permissions it provides, i.e. if you can’t do it in another way).
- It’s not traceable
- It can also violate RGPD and security. Imagine that you have permissions from a client to make modifications on a given subwiki only but not on others, using superadmin would violate that.
There’s another way, much better way. Create a service user with just the right permissions (like admin rights) and use that user. It’s also better because it doesn’t mix modifications done by the system under the superadmin users with user-made modifications under the superadmin user, thus providing better traceability. It also clearly shows to the rest of the users that a change was made and by whom (you’re not sneaking a change with them knowing). Also superadmin should not be active by default for security reasons. It should be turned off as soon as possible.
I don’t see the relationship with what we’re discussing. Using superadmin doesn’t allow you to impersonate anyone… It’s a unique user and nobody sees what it sees… We’re just talking about permissions here. And if you meant using superadmin to see what others are seeing then it’s not superadmin since superadmin is about permissions only and it has all permissions by definition.
Superadmin is a technical user. The most technical one actually. Thus it makes sense to provide the technical editor for it.
This is such an assumption that the “most technical user” is not supposed to be able to function without knowing the xwiki 2.x syntax in detail. I am also a technical user, and I sometimes use the wysiwyg editor because I just don’t know all the details of the syntax by heart (esp. the parameter names for the macros).
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.
Let’s not forget 2 details:
- Don’t forget that the “source” button is available for most of these wysiwyg editors, so if you want to take full control in a wysiwyg, you can use the source button which is there for that, for superadmin users but not only.
- Even if the button would not be present (because of fancy wysiwyg config) you’d still have the option to change the default editor in the settings to “text” and restart the wiki, since what Enygma was proposing here is to keep the current situation for the editor instead of changing it to text. But one would still be able to change it, if needed.
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.
Of course there is discussion that can be done here, and we could start discussing all the other parameters of the superadmin users that could be set, based on one usecase or another.
If the superadmin is only for the permissions system, then why are we even talking about the editor, since the editor is not used in creating users or changing rights.
Also, if it’s about writing a script as superadmin to programatically manipulate rights, please note that this is why admin is advanced user as well, to easily be able to access the wiki editor of a page to write a script in the “technical editor”, so I would say that about 80% of the “technical content” is covered.
Also, the editor of a textarea field of a class has a setting about what type of editor to display (wysiwyg, text, puretext) and this is supposed to be defined properly upon class definition, in coherence with the type of textarea (is it for content, is it for script), to make that object properly usable (e.g. ssx & jsx objects, wikicomponent objects, etc.). Most of these classes are defined properly in the standard distribution (otherwise it wouldn’t be possible to develop with a user that doesn’t have text editor as their default editor) so yet another category of content on which you shouldn’t be bothered by the fact that the wysiwyg editor is configured by default (since they are displayed w/ text editor).
I honestly see very little cases that remain impacted by the default editor of the superadmin, other than the inline forms for applications, which are mostly about content, and having another editor than the default one of the wiki would look much more like a bug than like a feature.
So let’s summarize so far from what I understand:
- Anca:
- +1 for UNDEFINED editor for superadmin by default
- 0 for Text editor for superadmin by default (since it’s possible to unset it)
- Vincent:
- +1 for Text editor for superadmin by default
- 0 for UNDEFINED editor for superadmin by default
- Edy:
- +1 for UNDEFINED editor for superadmin by default
- Thomas:
- ?
- Simon:
- ?
Let’s try to converge. Once we have Thomas’s and Simon’s positions that should be easy.
As I said my preference for personal needs goes to Text but I honestly don’t know what is the best to have by default. I’m fine with both and people voting for UNDEFINED seems to be insist more so I guess it’s the right one, at least it’s consistent with the default and I don’t see very strong arguments for Text.
Quite frankly I’m +0 for both solutions, since superadmin is advanced user, you can anyway chose which editor to use. So I’m really fine with both solutions.
Conclusion: I’m going for UNDEFINED, ie same behavior as what we had. Issue https://jira.xwiki.org/browse/XWIKI-17104 was closed as won’t fix.
Thanks everyone for the participation and voicing your opinions.