The following scenerios:
1. tony is a viewer, his group is a contributor
Outcome: tony is a contributor

2. tony is a contributor, his group is a viewer
Outcome: tony is a contributor

Then there is no way to be a viewer if a people with an assigned group no matter the page is set to be "Public".
The only way can do that is the people without a group.
However, it is difficult to let a person without group in a company.

So I am wondering if there is an improvement on this problem.
If the page is set to be public, the person can only view no matter his group is a contributor.

The permission system is "additive" meaning that your access level can only be increased (unless a page has restrictions, but that's a different topic).

So, if you want somebody to be just a "viewer" they need to only have the "viewer" right or less to begin with. Then, they can get granted the "contributor" right by a group".

Alternatively, the group can have "viewer" right and only users who were explicitly granted "contributor" right in the control panel will have that right.

Make sense?

Ok, trying this schema but with no luck.
Could it be caused by cache/(users, permissions, roles) parameters set to True???
I'm running Deki 8.05.2 and didn't upgrade to 8.05.2a.

You'll have to make the page semi-public. Public means that any contributor can edit it.

Just to clarify - and this really should be in the documentation so it can be known before someone installs/commits to using Deki Wiki -

There's only 3 practical scenarios for branches.

(1) A branch is public and everyone on the wiki can read/edit it.

(2) A branch is semi-public. This means
- Only designated individuals can edit it (committee leaders, etc.)
- Everyone on the wiki can read it.
- Its not possible to limit viewing to any particular committee or group.
- There's no way to mask or hide the branch.

(3) A branch is private. This means
- Only designated individuals have access to it
- But ALL of those designated individuals can edit it.
- Its not possible to have a "viewer only" for a private branch.
- All are contributors and there's no way to change that.

I'd really like to see finer grained permissions so that we're not limited to three scenarios.

Finer grained permissions for what end? Roles and groups allow you to control any non-edit permissions very well - delete/move/admin/restrict can be controlled very well, so the scope of the fine-grained permissions seems to be in the ability to control edit rights.

I've resisted any attempts to make the permissioning system more fine-grained, because it disrupts the balance between open collaboration and information lock down. In our office, we invite non-engineers into weekly developer meetings. It wouldn't be very nice if I told them to shut their traps and only listen

In the use cases I've read here in the forums and heard in the office, the ability to lock down a page for view and not edit within a branch of already trusted users seems to revolve around one major perceived problem: "What if this malicious user decided to edit this page with bad information?"

In traditional CMSes with no revision history, a malicious user can wreak a lot of havoc, so a fine-grained ACL system was necessary. In a wiki, this isn't a big of a problem - all changes are logged and are easily revert-able. There's always a balance between using technology to solve social problems, and leaving tribes to fix for the problem through social means. Wikis have generally tended to skew towards the latter.

This also doesn't take into account the technical considerations - design iterations revolving around updating the permission dialog to support fine-grained permissions have created such overly burdensome user interfaces that I've been loathe to implement them. This technical difficulty, coupled with the fact that implementation would only solve a few edge cases which come at the cost of potentially making the feature impossible to figure out for regular users ... and I just don't see the benefit of it.

I haven't yet run into an actual deployed wiki (Deki or otherwise) which suffered because of this lack of granularity - I've only seen questions from people *thinking* about deploying Deki raising these concerns (which are perfectly valid, but irrelevant once you see how Deki works)

Of course, if you launch multi-tenant Deki (treating each "branch" as an indvidual Deki instance), you can easily work around the first-level lack of granularity...

I get where you're coming from. In my own organizations, I'm really open about information and sharing. I believe in it.

But I tend to bring Wikis and other types of software to non-traditional users. For instance, a church, a small local corporation, etc. that has some traditions in hierarchy and also some need for information security (if the wiki is going to be used for finance, budgets, personnel issues, strategic planning, etc.) Its possible someone may wish to lock off as little as one page (a policy page) and keep the rest open, or something similar.

It makes it easier for me to bring a Wiki product to these clients if I can lock down certain pages or certain branches of the Wiki.

They're drawn to the idea of sharing information, and thats a huge first step for them. To make traditional organizations take the huge leap from not just sharing information, to also allowing open editing of information, is sometimes too big of a jump for them to make.

Since its possible technically, I don't see why the feature can't be available for those who might like to use it. We're not forcing anyone to use it, just making it available for special situations and for those who might like to. Especially since Deki Wiki is being advertised as having extremely customizable permission settings - thats a misnomer if all possible settings are not made available. I suppose some of my posting comes from being disappointed that this was not possible after I had such high expectations about being able to do anything with the permissions (the marketing department did a very good job emphasizing that!)

But that being said, I do truly see where you're coming from Roy... you're a Wiki'er at heart and thats a good thing. I guess it changes my job as a Wiki developer into someone who not only has to logistically convert paper orgs to online orgs, but also help them change their beliefs about information, on a deeper level.

This spawned a good conversation. Thanks for your post.

John

This is an implementation question, and it is actually impossible to pull off. It is not possible to have a "simple" mode and an "advanced" mode, because by nature, the advanced mode will contain data that the simple mode will not know how to handle or display. Attempting to merge those changes can lead to irregularities, which could cause people to think the feature "breaks."

Deki *does* support finer-grained permissions - there is no reason you couldn't build your own restriction dialog, using the API's features, to fulfill these needs - that's the beauty of open-source! And in the larger sense, Deki does provide a very powerful permissioning system - the haggling point that is raised is being able to distinguish view and edit among _trusted_ users (Semi-Private already allows you to differentiate between non-trusted self-registered users and trusted editors). Interestingly enough, Mark Pilgrim wrote a great blog post today about the ability for software writers to influence the users - and it's my personal belief that getting too granular with permissions is damaging than helpful and kills the open collaboration spirit, which is why I am so rabidly against this type of feature request every time it comes up

Thanks for the great convo, John. It's nice to get these thoughts aired out - I still believe that the concept of wikis and the mentality needed to foster their growth is still not mainstream, but when I see how well we use our own developer wiki, and how projects like Mozilla have deployed Deki for their large communities ... I really think once you embrace that shift ... it makes a huge difference.

While "Resistance against the Roy" may be futile , there are others who believe the Restriction Dialog should closer mimic the capabilities of the API.

Here is a concept of what such a dialog might look like.

Adding a user/group grantee:

1. select page restriction level from drop-down: public, semi-public, private (and othe custom restriction levels)
2. select grantee user or group
3. (optional) select granted role (default: contributor)
4. (optional) select grant expiration date (default: never)
5. click 'Add/Update'

Displaying grantees:

1. show user/group name
2. show granted role name (with low contrast)
3. show grant expiration, if any (with low contrast)

For example:

• RoyK (editor)
• SteveB (contributor until July 14, 2009)

Note: the information about "who" issued the grant could be revealed by hovering over the entry itself.

Edit a grantee:

1. select user/group -> fills settings for that user/group into same controls used to add a grant
2. (optional) modify granted role
3. (optional) modify grant expiration
4. click 'Add/Update'

Steve:
do you mean the modified role can be granted as a viewer although his orginal role is contributor??
If the e-mail system is replaced by wiki, some of the message I just want to grant someone to view instead of contribute, they can view and give comments only.
is it possible in later version?