I create a sample_page and assign it a private acces (only a few users can view or edit the page).
These users have the role of "COntributors".

I then create a new user, whose role is a "Viewer".
Now, this viewer can only view the pages, not edit them. (Thats the reason i assign him the role, Viewer)

While applying security permissions to sample_page, i add this user to the private access list of already available users.
Since there are only 3 options availble,

1. Public
2. Semi Public
3. Private

I cannot make this user only view this page.

My requirement is, only selected users can view or edit the page.
I would need all of the users having the role "contributor" to view and edit the page and all users havign the role "viewer" to only view the page.
All others should not be able to access this page.

This role and restrict level access is a little confusing.

"Restrict Access" seems to override the properties of "Role".

Adding a user to the list is a grant - it adds the list of permission flags as defined by the three options.

So regardless of what the user was prior to being added to that page, the restriction dialog adds those permissions, which is why viewer became a contributor.

So, how do we make a page read-only for specific users/groups/roles?!

We have a similar requirement in that our wiki will need to publish a page that only a specific customer can view. We'll be proving them with financial reports attached as PDF documents. We only want them to be able to see their reports, and don't want them to be able to delete or modify any portion of their page.

How do I solve this? Is Deki Wiki the right choice? Can we add a Read-Only restriction to facilitate this requirement?

Thanks,
Andrew

You can hit the API with a custom curl request to make this happen. It is currently not supported as a UI use case due to its specificity. I've written about my feelings on the matter in the past - your use case is specifically mentioned as an example.

The short answer: It'll come in a future release, but it's going to take a while to percolate into a fully tested, clean implementation that works with the existing restriction dialog. Unfortunately, the easiest solution ("make an advanced ui") would not work well here, because the data would simply not be supported in the simple ui (and could lead to data loss).

We have an ongoing internal debate on this issue. The problem is not the technology or even the implementation, we can facilitate many more scenarios than you could ever imagine. The problem is the user experience. Either we enable the full power of the underlying permission engine, but then the user interface complexity becomes staggerin, or we optimize for the user experience, but limit the capabilities. Choices, choices...

I can provide more info on the permission engine if someone wants to tackle the UI challenge for it