#696 "Allow file attachments" is not checked

[Stéphane Aulery]

Seems the "Allow file attachments" is not checked because I can add attachment to resources when this option is set to No.

[Mark Grimshaw]

As superadmin you can do anything including adding attachments when the option is disabled.

I've checked with another non-admin registered user and the option works as expected.

Mark

[Stéphane Aulery]

This may mean that I should not test with a superadmin account.

Thanks,

[Mark Grimshaw]

Indeed.

I have very bad practice in that I do everything on my wikindx with my superadmin account.

We should have a conversation sometime in the future about whether we allow this and/or how to handle the superadmin testing configuration. A normal admin can also add attachments when disabled.

We should have a conversation sometime about adding another class of user:
Superadmin

• Admin
  Registered user
  Read-only user

Currently, WIKINDX distinguishes the superadmin from an admin only by the userId == 1. I'm sure this is bad practice — what if another currently registered user takes over a departing superadmin's job; what if you need more than one superadmin (large organisation, large WIKINDX); etc? Which are the superadmin functions a normal admin cannot do?

Mark

[Stéphane Aulery]

We start a discussion about that by email and save something in [#537].

A normal admin can also add attachments when disabled.

If it were me I wouldn't allow it to admins if it's disabled, except the ability to delete attachments already added.

Currently, WIKINDX distinguishes the superadmin from an admin only by the userId == 1. I'm sure this is bad practice — what if another currently registered user takes over a departing superadmin's job; what if you need more than one superadmin (large organisation, large WIKINDX); etc? Which are the superadmin functions a normal admin cannot do?

An inventory of existing exceptions should be made first.

We should have a conversation sometime about adding another class of user:
Superadmin
+ Admin
Registered user
Read-only user

Do you want to add read-only users?

[Mark Grimshaw]

The classes of user I list are those used for programming in WIKINDX generally (not just limited to attachments). A read-only user is simply a user who doesn't exist in the database—thus a conceptual user rather than a real user. I'm not suggesting adding them to the database.

[Stéphane Aulery]

So, what user class do you want to add?

[Mark Grimshaw]

The ‘Admin’ class.

[Stéphane Aulery]

But there is already admins. Isn't it?

[Mark Grimshaw]

There's a flag for admin status in the user table. Currently, though, the only way to distinuish a superadmin from another admin is by the userId (which must be 1 for the superadmin). Much better, I think to have the explicit flag for a superadmin (perhaps a large organisation has more than one superadmin or the existing superadmin (userId = 1) is retiring (as superadmin but wishes to remain active as a registered user) and must transfer superadmin duties to another registered user (userId != 1).

[Stéphane Aulery]

For my part, I think that the Superadmin role is not necessary at all for the update. Instead of trying to authenticate a user the update procedure could use a token configured in config.php for the authentification. Token that does not need to be encrypted like a real password because it does not allow to administer the site, only to update it.

That's why I'm trying to find out if the SuperAdmin has another role that cannot be assigned to an admin.

It remains true that the transmission of the admin role must be correctly managed, as you say.