Feature Request: Group based granular access control

[scott.harman]

I'd like to restrict certain user groups from having any access to a category of documents, to separate out read-only permissions from write permissions etc

i.e. i'd like to explicitly prevent helpdesk from having access to wiki pages in the R&D category, where new features are discussed and developed, and I'd like to give engineers the ability to read documents that are in the category released, but not to edit - then i'd like to give them the ability to edit documents in the draft category, but not to move them into the released category.

this is an example of the workflow my management would like to follow, as then it follows the document management path of Lotus Scrotes (*spit*)
I personally think we can trust our engineers and helpdesk staff, but a more robust set of rules for document management would be useful, so if the page permissions can be inherited from the category which explicitly denies or grants access - that would be really sweet ;)

[Petrus4]

If you have an external authentication service like Active Directory or openLDAP you can use existing security groups to grant or deny read/write or write access. This also applies to moving any page to another category for a user who does not have write or read/write rights, this would not be possible. You can also set up sub-pages to inherit the restrictions of the main page. Deki Wiki does not have its own local user group management system (yet) therefore, if you only have local user accounts, you would have to add the individual users one by one in the page restriction dialog .

I hope that answers your questions.:)

[scott.harman]

Gidday,
I'd just like to be able to specify which groups have a particular type of access
i.e.
under restrict access:

Restriction Type:
Public: everybody can view and edit
Semi-Public: everybody can view, but only selected users can edit
Private: only selected users can view and edit this page
Grant List

Find User or Group:
...
i can seperate out the read access from the edit access, so users may read but not edit, that would be ideal, and I don't want everybody to read certain areas - just certain user groups.

[Petrus4]

Hi Scott, I am a bit confuse by your post:confused:

It seems that Deki Wiki can do you what you want if you have LDAP or MS AD and the security groups configured in the service you are using.

Do you have any of these external authentication services enabled on you deki Wiki?

You can get more info about this here: LDAP and MS Active Directory Integration (http://wiki.opengarden.org/index.php?title=Deki_Wiki/FAQ/User_Management/How_do_I...Integrate_my_users_with_LDAP%2F%2FMS_Ac tive_Directory%3F)

What version of Deki Wiki are your running?

[royk]

Petrus, as I understand it, I think this person wants the ability to not just apply "Semi-Public" to "Group A", but also apply "Private" to "Group B"

Currently, the API supports this, but our user interface doesn't. Our restriction dialog has always been designed to be as simple as possible (those of you who have worked with more advanced access control features have understood the complexity that can entail with more permissions). That said, if there is more of a demand over the coming weeks for exposing some of the advanced functionality of the API, we'll definitely take a look at revamping that dialog.

[Petrus4]

Ok I see.:o Sorry I misunderstood your request Scott, and yes this would be a good addition!

thanks for the Clarification Royk.

[mystikweb]

Hi there, I would definately like to see the granular approach in the permssions/restrictions so that:

So that you could apply group restrictions to a parent and its children in the way that:

Group 1 would have READ ONLY access
Group 2 would have READ and EDIT access

As we have areas that need to be edited by a particular group, and read only for another single group, where the the other groups cannot view the pages at all.......

This would definately be a usefull feature......

Any comments?

[royk]

These features are mostly supported by the API already, it's a matter of modifying the UI to work against these cases.

It sounds like in general, we need an 'advanced' restriction mode which would expose some of these behaviors. We need to capture all the threads (like this one (http://forums.opengarden.org/showthread.php?t=1902)) which talk about expanding the permissioning feature to aggregate into a spec.

[mystikweb]

That sounds great, and as you said if its somewhat already there, its the matter of exposing them so that the permissions can be set :-)

[cet]

Hi all,

Better restriction and group management would definitely help. Our story is similar to Scott's, in that we have imported a whole bunch of users (not administered by us) and we only want some of them to be able to access all the content. I've created two groups in group management: 'FullAccess' & 'RestrictedAccess' but I cannot add users to these groups! If I could, it would make setting permissions much easier (and as already mentioned you could click Restrict Access and then select a group, rather than adding individuals).

Any word on when features like this will be available?

[bighorton]

I'm running into the same issue. I have a page that I need to restrict so that only two groups of people (who are defined in Active Directory) have access to a specific page and it's children. One group to have read-only access, the other group to have edit access.

I attempted to create this arrangement through a combination of restrictions and roles, like so:

Page is "Network Stuff"
Users are Joe, Bob, Sue, Steve, and Bruce; listed in Active Directory.
Active Directory group "WikiReaders" includes Job, Bob, and Sue, and that group has the role of "Viewer" in Deki.
Active Directory group "WikiEditors" includes Steve and Bruce, and that group has the role of "Contributor" in Deki.
The page "Network Stuff" is set to "Private" and includes the groups "WikiReaders" and "WikiEditors".

Unfortunately, even though the group "WikiReaders" has the role of "Viewer" - the people in that group still get edit access to the page "Network Stuff" - the page restriction is overriding the role, instead of working with the role. So - could this behavior be changed? Set up so that the page restriction grants the abilities that are already defined in the group (or user) role instead of just handing over edit rights?

Anyway - I don't know if I've explained my thinking clearly, or if I've missed something. It just seemed like you've already got everything you need to provide this type of functionality, without really changing the interface.

My $0.02...!

Scott

[royk]

Although I agree that in the future this is the type of functionality that might be useful, I don't foresee us addressing them.

When designing our restrict pages' UI, we had to balance simplicity vs. functionality. We purposely did not expose the full API underneath because of its complexity. For an example of a dumb UI which simply exposes the UI underneath, take a look at the roles management screen.

The benefits of the simplified permissioning is that it boils down permissions to something all end-users can understand: viewing and editing. Exposing the whole set of permission masks to every page restriction will create a burdensome, complex UI (try to manage Roles in the Control Panel). Not only this, but if individual users or groups have different permission masks, you are quickly gonna run into information overload. And to expect anybody with restriction access to either implicitly know what each role means, or to understand the bitmasks (understand BROWSE vs. VIEW) is too much to ask of users.

The specific case mentioned here is: "I want Group A to read, Group B to read+write". This is an extremely granular case of control: why would it not be acceptable to have Group A + Group B both be able to write? I can understand on other CMS systems, where there is no ability to revert changes, this could be a damaging issue. However, in a wiki, this issue is not as severe - you simply revert the bad change from unnecessary users.

Wikis, (like Wikipedia), thrive on accepting contributions from as many sources as possible, then manually creating a blacklist of changes (through revert). In the projects I've worked on, the whitelist access mentality (popular with Drupal and such) have always ended up in frustration, as contributions end up funneling through one person who must make a decision about who gets access to what. The strength of wikis is the implicit trust system, with the safety net of reverts. This reduces the overhead and the top-down organization required for content collaboration.

I don't dispute that there might be use cases for granular group control, but I'd try to view your use cases through the lens of a wiki, rather than through those of traditional CMSes. I actually feel this type of functionality plays against the strength of the wikis.

Of course, if somebody can convince me with use cases that this type of functionality is worth the complexity that accompanies more granular control, I'm all ears :)

[vastpark]

I agree that the simplicity of whitelist permissions help build an active community and such, but I think Deki Wiki is so lovely many of us want to extend how we use it to cover running more functions because it temps us with more functions! That's a good thing, but it leaves me wanting to run a few of my customers and project websites using Deki Wiki. Of course I could use Drupal or Joomla to do the traditional CMS thing and perhaps given the lack of granularity with permissions I will be forced to, but I think some of us are crying out for some greater control so we can assign people to groups or levels of trust (Admin, Publisher, Editor, Member, Guest). It would make a lot of difference to how we use Deki Wiki in the future if one of my non-programmers can determine the logic of allowing users to comment on all pages that accept comments, but choose which pages members can edit. Any of my team, right down to my marketing person, could work that out I promise you. It would be even easier if we can set up some broad site wide rules which apply on all pages unless you choose to override on individual pages (and optionally their children).

That's my 2 cents as well. If we all keep going this might end up worth a dollar. ;-)

[graynotgrey]

Add my vote to more granular access control. I too am leaning toward wanting to use Deki Wiki instead of Joomla and Drupal for web sites, but more granular permissions may be necessary, but they need not be that complicated. Take a look at the rights management for Xwiki, a Java based wiki:
http://platform.xwiki.org/xwiki/bin/view/Features/RightsManagement

The checkboxes in rows and columns are fairly straight forward and easy to use I think. Yes, it similar to the roles interface.

Maybe there could be two interfaces to the API, a Simple (the current UI which could be enabled by default) and an Advanced tab or interface for those that want more control which would be optional.

[royk]

Maybe there could be two interfaces to the API, a Simple (the current UI which could be enabled by default) and an Advanced tab or interface for those that want more control which would be optional.

This is an alternative we discussed; the problem is that the 'Advanced' mode would not degrade into the 'Simple' mode, and we would have to add checks to determine which "type" of restriction it is.

[royk]

I should note that Deki Wiki already offers user->group management, and role management, which accomplishes most of these tasks. The point I made above is page-level granular permissioning - you can already accomplish a lot by using roles. I urge people who are looking for granular permissioning to take a look at roles.

[bohappa]

Here is my business case: enterprise knowledge base. Let me know if it qualifies as a useful exception:

SMEs create a page. This is my draft content.

When the draft content is correct, I want to publish it. It becomes published content and represents the official knowledge base. No noise. Just facts.

I want guests or non-SMEs to view but NOT edit published content.

To this point, roles work fine. But here's the catch:

I want to allow SMEs to continue discussing or improving the draft content until it is ready for re-release. Drupal, for example, supports a draft/published version of content. Wikis, afaik, do not.

So, I think in Deki I'll have to version my content by basically making a duplicate page in a separate node.
DRAFT Content
---page1--draft
PUBLISHED Content
--page1--published

I think I would have to manually make and maintain two copies of the same page. For non-SMEs, I want to make draft content invisible, which means I can't do page transclusions.

I still believe a wiki is the way to go because I have a lot of SMEs that need to collaborate and I've confirmed that they like Deki to do this. I'm just trying to figure out how to support two views or versions of one page without making my own life hell. I suspect more granular access control would allow me to define parts of the page in the draft node as visible to non-SMEs.

Either a page could support a type of content, such as SME Comments, or section/page level entitlement overrides. I could instruct my SMEs to edit only some sections on a page, or use a special reviewer comment that is hidden from non-SME users. In this way, they can continue improving information but still allow non-SME users to have access the last approved version.

In the simplest analogy, it is like embedding comments or conditional text in a document. Viewers with insufficient privileges do not see it.

If you know a way to meet this requirement without modifying DW, please let me know.

[beezoboy]

Two pages could work.

Could you set up one page as private and then use wiki.page to display it as a read only version for the people who need read only access? This way if they go to edit all they get is the wiki.page command.

Its a little bit of a pain but at least you don't have to worry about maintaining two seperate pages.

As far as user access and group access goes. Would having a group permission level (if specified on the page) override the user if in that group be hard to set up? Seems like a simple if-then statement would handle it. This is how windows server handles things with always applying "most restrictive permissions".

[bohappa]

I'm not sure I followed your explanation. I did test the wiki.page transclusion but it achieve the desired affect. The published page only displays "restricted page" because it points to a page that the user is not allowed to see.

I suspect the most elegant approach is to support two views of a page: one published and one draft, like a CMS does (e.g. Drupal).

I do not think this feature is inherently contrary to the spirit of a wiki. Rather, it enables quality content creation. Sometimes a team wants to publish to other teams/departments validated content ("The findings of this team are...") while still enjoying privately the extensive collaboration features of a wiki "We can't say that, it's bullocks!".

[beezoboy]

Hmm thats odd. I use my DekiWiki for an intranet. Right now it is set so that there is a public section, which requires no login to see. Then there are departmental sections which are set to private. However I have a news section on the front page which pulls 2 feeds and news from a restricted portion of the site. I have no problems.

Home
|__ Public- General Resources
|__ Private- Department1
|__ Private- Department2

And so forth. . . My Wiki pulls content from "Department 2" which populates the "news" section on our public section using wiki.page. I do have anonymous allowed and I have no LDAP.

Not sure why it works for me and not you.

-B

[royk]

bohappa,

Your use case is actually solved with our new "Talk" pages feature - each page has an associated talk page (much like MediaWiki). For your case, I'd make the main article editable by only a few (but viewable to all), and make the talk page edit/viewable by all.

[bohappa]

Yeah, I'll try that. Thank you for the suggestion.

It doesn't solve the case where I haven't made a page public yet and want it to be hidden, but I guess this can be handled in other ways (like making a DRAFT tree) and then moving content the the published node when it is ready.

Just out of curiosity, what is the design for transcluded content and entitlement. Should transcluded content retain entitlement defined by original page? I think this is the design.

Or, does the transcluded content inherit the entitlement for the context in which it is being used?

[cody]

We now have one wiki with no external user management, and we'd like to be able to create two groups - staff and users, then assign people to those groups.

Staff would naturally have full access to all articles. Users would only have full access to a selection of articles, and no access to others. As we create articles we'd assign which of the two groups (or both) has access to the page.

I don't think it can currently do this, based on what I've seen in control panel and what I've read here. If I'm wrong please correct me.

Thanks

[bohappa]

You should be able to achieve your objective by defining roles in Role Management (Control Panel). There are some default roles that may be sufficient. You can also define your own.

[strannik]

Ok,

I understand on how I can use roles to manage groups of users and define their rights to the whole wiki, but how can I use roles to define which users/groups can modify a *part* of any given tree starting from any given point that i need or just any specific pages. or to give a user the right to view this page and that page (from different trees) but to be able to edit only a specific one of them?

I'm not using an ldap server, i will not be needing it for the user count that this exact wiki will have.

Thanks in advance.

[cody]

Ok,

I understand on how I can use roles to manage groups of users and define their rights to the whole wiki, but how can I use roles to define which users/groups can modify a *part* of any given tree starting from any given point that i need or just any specific pages. or to give a user the right to view this page and that page (from different trees) but to be able to edit only a specific one of them?

I'm not using an ldap server, i will not be needing it for the user count that this exact wiki will have.

Thanks in advance.

What I did on mine was create two groups - one as staff and the other as users, both being contributors, and assigned all the logins to one of the two groups. Then on the top-level pages we use "restrict access" so that all pages are public, except the trees that we want to keep for staff only. Those we mark use "restrict access" to mark as private and give access to the staff group only. It also has the nice effect of making everything underneath that private also, so we have a whole "Internal" tree that nobody can see but us.

So we have a wiki that anyone can read, that only people who sign up can edit, and with private pages that only staff have access to.

Is that different to what you want?