Have superadmin and guest settings configurable

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.

:slight_smile: 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.