Feature Proposal: Prevent Accidental Lockout of Topics

Motivation

In a corporate setting, people like to restrict page access. Sadly, they misspell, they get confused about user name format, they misunderstand how restrictions are done.

Where I work, the most common support request is "Help! I locked myself out of this page (somehow)"

We should give them an "are you sure?" before they lock themselves out of a page.

Description and Documentation

Before finishing the save, check the new privileges. If the user will not be able to view and/or change after the save, transfer to an Oops page with a warning "You are about to restrict access to this page. After saving you will not be able to (view/edit) this age again. Are you SURE you want to save this page with these restrictions?"

Or words to that effect.

Examples

Impact

WhatDoesItAffect:

User Support requests

edit

Implementation

-- Contributors: VickiBrown - 20 Apr 2009

Discussion

This is a dammed good proposal.

Now can I code this one myself? Not sure. But with a co-developer I would for sure love to help testing it and documenting it.

It would be 1.1 scope but maybe we can make quickly an extension that can do this?

-- KennethLavrsen - 20 Apr 2009

Mmm, by thinking a bit of it I guess the proper easy way to handle this and similar problems should be to place code in error situations, and then try if we can detect a correctable situation and propose a fix. In this case, this would give:

• If we try to view a topic, and viewing it is denied, engine checks if last edit was by us, and then report the situation and offer to fix it (edit anyway)
• If we try to edit a topic, and change is denied, engine checks if last edit was by us, and then report the situation and offer to fix it (edit anyway)

The advantage is that there is no complex logic to code (we already are in the error), no performance degradation (code added only in error cases). The problem of this solution is that it only address one side of the problem, and not the other: the common mistake where people make a typo and unwillingly unprotect a topic.

-- ColasNahaboo - 20 Apr 2009

Not sure of the performance ramifications but both VickiBrown and ColasNahaboo 's concerns might be best alleviated by a check like Vicki's proposed above that simply determines that access will change somehow and adds a confirmation screen.

You have changed the access settings for foo web or foo topic from old perms to new perms. Do you wish to continue?

A setting to disable the check could be added for the bold/easily annoyed.

-- DrewStevenson - 20 Apr 2009

i hate useless confirmation dialog boxes---don't you, too? and, all confirmation dialog boxes are useless. do you read all of the text? do you automatically press "OK"? even if you don't (and you probably do), that is what your users will do. better to offer some sort of undo facility.

-- WillNorris - 20 Apr 2009

iirc, WebPermissionsPlugin has some code in it to prevent you from locking yourself out. The UI team where talking about using that Plugin to prototype a more friendly UI for topic permissions (there's a topic somewhere)...

-- SvenDowideit - 21 Apr 2009

Probably the most common mistake I've seen is our users who create a group and forget the "Group" suffix. Then lock the group topic to the group that is not a group. It would be most helpful if this could be prevented.

-- GeorgeClark - 21 Apr 2009

Presumably you are talking about detecting the simple "I edited the topic and now I can't see my own feet any more" problem. However there are a number of reasons for disappearing toes:

1. If someone changes a group topic, and a user is locked out. they have been locked out (somehow)
2. If someone changes WebPreferences they can be locked out (somehow)
3. If a plugin (e.g. WorkflowPlugin) steps in and says NO! they can be locked out (somehow)

Personally I don't like confirmation dialogs any more than Will, especially dialogs that only tell you what went wrong some of the time. The way I look at it, we are missing two things:

1. A simple way to get a summary of the permissions on a topic even if you can't VIEW the topic itself
2. Restructure access controls so you can still edit when you performed the last edit.

With (2) I'm not sure you even need (1).

-- CrawfordCurrie - 21 Apr 2009

Confirmation dialogs are only a problem when they appear often. So if there is to be a confirmation dialog, then the dialog should only appear when I am about to shoot myself in the foot, and not at any other time. And there may be cases where there should not be a dialog (perhaps related to a plugin like WorkflowPlugin (which I am not familar with)) even though the change I make prevents me from making future changes to a topic.

I like CDot's suggestion of restructuring access controls. It would mean that users no longer know that they have locked themselves out. That could be a problem if someone else (who still has access) edits the topic and causes my change to the access controls to take effect.

-- MichaelTempest - 21 Apr 2009

The biggest problem with the access stuff is that you have todo it in wikimark-up or wysiwyg. Which is insane.

Just look at this confluence example and you automatically understand how it works. You cant say this about foswikis access right handling..

-- Carlo

Which is why I keep bringing up WebPermissionsPlugin - which already has a group and user selection dialog for the topic permissions. All its waiting for is a UI person to tweak the tmpl files that define the UI

mmm, and to be ported to foswiki?

-- SvenDowideit - 21 Apr 2009

I'm not in favour of letting the last person who edited a topic to continue editing it, regardless of the access controls setting. This is akin to a topic ownership concept, in which case, I prefer that it be explicit rather than implicit, so ownership can be reassigned.

-- IsaacLin - 21 Apr 2009