Show Advanced KnowledgeHide Advanced Knowledge

Extending User Activities for Page Editing, Protecting and Deleting

1 Requirements

 
A) Individual switching "on/off" of the function "Set Read-Only"
In collaborative wikis it makes sense, that users with the permission "Edit Content" can activate the "Set Read-Only" function and can delete a page.
The functions should be configurable through the wiki-owner on the setting page.
 
 
 
B) Individual switching "on/off" of the function "Wiki Navigation"
In the area "Wiki Navigation" existing wiki pages can be added and removed to the "Wiki Navigation" block.
The function is now implemented in the "Edit Settings" permission. For users, who have the permisson "Edit Content" this function should be turned on separately in the wiki settings.
 

The functions will be presented in the block "Wiki Functions" in the dropdown-menu "Page Actions", if they are activated.

Definition of the "Set Read-Only" function
 
szenario 1) as in the current version
 
If the "read-only" function is set on a specific wiki page, only users with the permission "Edit Settings" can edit that page.
 

szenario 2) Users with the "edit content" permission
 
Users with the "edit content" permission can activate the "read-only" function for all wiki pages. This function can be deactivated by the activator, by the wiki owner or users with the permission "Edit Settings".
 
If the protection of the page is activated, the function "Set Read-Only" is hidden for a user with the "Content Edit" permission (in the dropdown menu "Page Actions» in the block "wiki functions").
 
Instead, on top of the page the message "Page is read-only" appears.  (Already implemented.)
 
 

1.1 Alex Killing, 12 June 2014

Introducing permissions for these "settings" has the advantages that

• they can be set by role definitions and templates and
• they can be activated "per role".

It has the disadvantage that

• this can only be set on the permission screen.

There are similar scenarios in other ILIAS objects. I think this leads to a more general requirement:

Users that are "object admins" (can edit the settings of an object) need to be able to set "low level permissions" without having the full "edit permissions" permission. E.g. tutors need to be able to control what learners can do with an object without having access to the full permission screen.

So in the case of the Wiki, I support the idea pointed out by Sarah and Werner in their comment from 21 May: It should be possible for users with "edit settings" permission to set these permission, e.g. on the editing screen. But there is one important issue: The permissions are set "per role". To have a consistent mapping from the editing screen to the permission screen, roles must be listed. However this could be limited to roles that have "edit content" permission but no "edit settings" permission.

E.g. given a wiki where two roles have "edit content" but not "edit settings" permission:

• a local course member role "Course Member" of an upper course
• a global "Learner" role

In this case the screen could look like this:

This would "expose role titles to the tutor". I have no idea how to avoid this if we go this way.

2 Additional Information

• Idea / concept: Sarah Schilling, Werner Willi, werner.willi@phzh.ch
• Funding: PH Zürich
• Maintainer: (will be set by Jour Fixe)
• Implementation of the feature is done by (company, developer)
• Contract settled: "No"
  
• Tested by / status: (name, e-mail), (status information set after implementation)

3 Discussion

Alex Killing, 14 Apr 2014: This needs a JF discussion.
 
A) "Set Read-only" @JF: Is the activation a setting or a permission? Is the behaviour ok, or too complex/hard to understand?
B) "Allow Editing of Navigation Block": @JF: Setting or permission?
C) "Allow Page Deletion": There is no C) above, but somehow implicitly in A) and in the screenshot. The JF already discussed this issue in Mantis Bug 11246, outlined alternatives in the report have been a permission or an easy way to recover a page. This request asks for a setting now.

Sarah Schilling, Werner Willi 21 Mai 2014:
 
A) "Set Read-only" @JF: Is the activation a setting or a permission?
We think, that a wiki admin (=user with “edit settings” permission) should adapt all options on the setting page / ribbon.
 
We don’t want that our wiki admins make changes on the permissions ribbon. Only ILIAS admins should adapt permissions there – and only in very specific contexts / situations – as it is usually too complex for „normal“ group / course admins.
Therefore we think it should never be necessary that a wiki admin has to make any changes on the permissions to use different (wiki) options / functions / behaviours.
If you think, it must be a permission, it would be nice, that the permission can be switched "on/off" on the setting page, too. The wiki admin shouldn’t realize that a permission is adapted while any of these functions is switched on/off.
 
 
B) "Allow Editing of Navigation Block": @JF: Setting or permission?
as mentioned above
 
C) "Allow Page Deletion":
as mentioned above

Alex Killing, 12 June 2014: @Sarah/@Werner, I like the idea to enable the permissions of certain settings outside of the usual permission screen. I added a section "Alex Killing, 12 June 2014" to the requirements specification above. Please let me know, if something like this would be acceptable.

Sarah Schilling, Werner Willi 20 June 2014:
 
We support this suggestion and the solution outlined in 1.1 by Alex Killing, June 12. We prefer, that a tutor can adjust the permissions listed on the wiki settings dialogue, as mentioned in the general requirement paragraph. If this is not possible: either the check boxes should be shown grayed out / disabled
or the tutor gets an appropriate feedback when saving the permission changes.
 
We also support the idea of adding a fourth permission for the HTML export as mentioned Alex Killing, 12 June 2014 in HTML Export Extensions.

JF 7 July 2014: We support a solution of the general issue: The access of users to certain permission without the full "edit permission" permission should be possible. We think that a settings screen is not the best location for this access, since settings screens are differ in the organisation and the complexity in the various repository object types. We suggest a general tab for these cases, a simplified replacement of the current permission tab. However did not come to a final conclusion for the following points:

• Naming: How should the tab be called. If we call it "Permissions" it could be confusing, since users would not expect access to such a screen if "edit permission" is not given.
• Permissions: Should the access to the "low level" permission be controlled by the "write (edit settings)" permission or do we need another new permission to handle this?

This was the last point on the agenda of the JF today, we were not able to finish the discussion.

MK, AK, 5.12.2014: We think a separate tab being called "Permission" would be ok, since users would either see the default permission tab (if "edit_permission" is given) or this new tab (if "edit settings" given, but no "edit permission" given). The new screen should contain an information text that this is only a limited view on the permissions. We think that controlling this screen per "edit settings" is ok and we need not another new permission to do this.

Werner Willi, Sarah Schilling, 20 March 2015:
Although we understand your points for the separate permissions tab, we would still prefer to have those four additional permissions listed on the settings tab, like the newly added section "Activate Additional Wiki Page Properties" with "Feature Status", "Eigenschaften Blatt / Blüte" a.s.o).
There are three reasons for that:

1. We think the settings page is easier accessible, as the link is listed in the "Wiki funcitions" whereas the permissions tab is only accessible in two (main) steps (Settings > Permissions). Ordinary users (Wiki Admins = users obtaining the edit settings permission) often have problems to find hidden options.
2. If an organisation normally hides the current permissions tab for ordinary users, why would one look for additional "options"[1] on a separate (main) tab? Most objects have only one settings tab (probably with subtabs) for all options ordinary users usually alter. If an organisation allows the ordinary users to see the permissions tab, it is still not a tab where users makes changes. It is too complicated for them and they don't understand the meaning of the different permissions. We usually advise them not to touch any of the permissions in order not to break anything. So why should they search for those practical "options" on that permissions tab or even touch them?
3. An ordinary user might not see a difference between "options" situated on the settings tab like "Enable Rating", enable "Public Comments"  etc. on the one hand and enabling the right to "delete pages", enabling "HTML export" etc on the other hand. Therefore one might not search for those "options" on a permissions tab nor would one find those new "options" if they are not presented on the settings tab.

Suggestion / Compromise:
What if you create a new subtab on the settings tab, similar to the settings of "wiki navigation" or "page templates"? It might be called "advanced settings" (erweiterte Einstellungen) or „additional functions" (zusätzliche Funktionen).
 
Our main intention is to simplify the wiki for ordinary users by taking their point of view. The wiki isn't used so often as it is considered to be complicated and requires quite a wide knowledge of the users. They just don’t dare to use it. We would like that the wiki can be used by any normal user as it is a very practical and sophisticated tool for collaborative learning. There should be as few technical issues / obstacles as possible.

Killing, Alexander [alex], 6. July 2015: I support this request.

• I do not think we should/need to introduce another permission to control the low level permissions, "Edit Settings/Write" permission should be ok.
• A new subtab on the settings screen as suggested by Werner and Sarah would be fine for me, too. Naming of this tab could still be discussed.

JourFixe, ILIAS [jourfixe], 13 July 2015: We support the idea to use a subtab under settings and schedule the feature for 5.1.

4 Implementation

Killing, Alexander [alex], 11 Aug 2015: This will be available on the edge installation with the next update.

Neu "Permission Settings" subtab under settings:

Test Cases

Test cases completed at 2015-08-17 by Alexandra Tödt 

• http://testrail.ilias.de/index.php?/cases/view/6198: C6198 Beschränkte Vergabe von Rechten konfigurieren
• http://testrail.ilias.de/index.php?/cases/view/6199: C6199 HTML-Download aus "Wiki-Funktionen"

Approval

Tested successfully and approved at 2015-08-26 by Werner Willi. 

---