Loading...
 
Features / Usability

Features / Usability


Groups and Permissions question

posts: 3665 United States

cry I'm having problems getting my permissions to work properly...

I have Anonymous users who have read-only access to my wiki pages. Registered users have full edit access to my wiki pages.

However, there are some pages that I want to give write access to only specific groups. So on the page's permission, I assigned tiki_p_edit to the group Foo for the page. But now, no one (neither Anonymous nor Registered) can even see the page.

Surely I'm doing something wrong..... I want all users who are not in group Footo still have all read permissions.

posts: 4656 Japan

Try explicitly setting tiki_p_view for Anonymous on those pages. I ran into the same problem. I don't know if how Tiki handles perms changed at some point, but I also found that when I set an edit permission for one group, then other groups could no longer view the page, which is not the way I recall things working before.

-- Gary

posts: 3665 United States

Yes, this works, but.... I also want Anonymous users to read comments (tiki_p_wiki_view_comments), attachments (tiki_p_view_attachments), and several other things. If I have to assign my permissions on a page-by-page basis, what's the point of having groups?

It appears (to me) that the page-specific permissions override the standard permissions, instead of working in tandem (which is what I would expect).

-Rick

> Try explicitly setting tiki_p_view for Anonymous on those pages. I ran into the same problem. I don't know if how Tiki handles perms changed at some point, but I also found that when I set an edit permission for one group, then other groups could no longer view the page, which is not the way I recall things working before.
>
> — Gary


posts: 131 Singapore

I understand how you feel on permissions assignment as I have the same problem as you do. See my post here.

Colorado suggested using Categories to control the permission assignment, but Gary (and I) has tried it without achieving the effect intended. The tedious way out is to assign specific permissions to users in the wiki pages.

I have tried setting up the Category (v1.9.1) to have 2 category objects - public and internal- and then assign Anonoymous and Registered permission rights respectively in the Category permission settings for a specific user. i think that by creating a separate Internal and Public category would circumvent the issue of permission assignment. Putting documents/objects you want a group to view only in Public category seems to work. Not only that the Internal category does not display, even if the objects display, they are denied access with a "permission denial" page. Using search function to try and see whether it can uncover the page would turn in a negative search results also. This might not be a good way but so far it works to my expectation. Gary might have some reservation here....wink

I would love if someone can throw more light into this...

-- kwow

posts: 4656 Japan

> Gary might have some reservation here....wink

http://zukakakina.com/tiki-index.php?page=PermsTest

I think associating permissions with Tiki Categories is a work in progress, or at least a goal, but in the testing I did with 1.9.1 or so, pages didn't take on the perms of other pages in a Category. Am I missing something?

-- Gary


posts: 1092

As soon as you set a perm on a page, all others perms rules are ignored
I did this on the page with 1.9.2
Anonymous tiki_p_view
Anonymous tiki_p_wiki_view_comments
Teachers tiki_p_edit
Teachers tiki_p_view

Anononymous and registered can see page but can't edit
Anononymous and registered can see comment but can edit if tiki_p_edit_comment is on , can't edit otherwise.
Teachers user can see and edit page and comment

Note that I did a couple of perms fixes for 1.9.2. The fixes were to distinguish comment perms and forums perms. Please tell me if more issue on 1.9.2.

sylvie

PS: in 1.10 if everything is going right we will introduce the notion of perm set. A perm set is a list of perms (for instance the perms above will be able to be set with one click), like this it will be easier to configure perms

posts: 3665 United States

> As soon as you set a perm on a page, all others perms rules are ignored

So there's no concept of a global or default set of permissions? The only way is to explicitly assign all the individual permissions on a page-by-page basis? That seems like a lot of work to me.... sad

posts: 1092

> > As soon as you set a perm on a page, all others perms rules are ignored
>
> So there's no concept of a global or default set of permissions? The only way is to explicitly assign all the individual permissions on a page-by-page basis? That seems like a lot of work to me.... sad
Yes the categories system must be changed a little bit to be able to do that - add a tiki_p_edit_categories
On the list for 1.10 too

sylvie

posts: 3665 United States

Thanks Sylvie. Is there a list of proposed or pending 1.10 features?

-Rick


> > > As soon as you set a perm on a page, all others perms rules are ignored
> >
> > So there's no concept of a global or default set of permissions? The only way is to explicitly assign all the individual permissions on a page-by-page basis? That seems like a lot of work to me.... sad
> Yes the categories system must be changed a little bit to be able to do that - add a tiki_p_edit_categories
> On the list for 1.10 too
>
> sylvie

posts: 1092

I did the tiki_p_edit_categories yesterday.biggrin Some more test and I will commit. No there is no real list as we depend on the sponsors and the free time of the developpers.
sylvie


posts: 29

I've been trying to set up a category Drafts set of permissions so that editors can work outside public view until pages are ready for public viewing, then switch the category assignment to pop the page into view for Registered and Anonymous. I haven't got it to function the way I want yet, but think I'm getting close.

Sylvie, if you are working on permissions for 1.10, it would be a really nice touch if another button were added to the editing screen called "Save." Save would save the editor's work but keep it private from all others with equal or lower permissions, including all other editors, until the "Post" button was used. As the scheme works now, people have a lot of incentive to not save their work until they have completed a page because saving displays the incomplete page. I can set this up with per-user permissions now, but an application level change seems appropriate.

Regards,

Marbux


posts: 8 Italy

Hi,

I guess we have the same need. I tried to make a more-or-less formal description of what I need:

I need to have groups of pages in the same wiki that are restricted to specific groups.
In other words, I'd like to have groups of pages with specific wiki permissions set for each user group. Categories seem the right tool.
Right now permissions to see, edit, delete a page are defined by an user's status. I'd like to define them by the user's status AND the page category (logical AND to be on the safe side).

The idea is to assign wiki related permissions to categories. Right now I see that I can only set tik_p_view_categories and tiki_p_admin_categories as permissions for a specific group. I'd like to set permissions like tiki_p_edit as well.

Those permissions should be stronger than global but weaker than per-page permissions.

Then the difficult question: how are categories inherited in new pages created by users of different groups?
Each user should be able to move the page he just created to any category he can create pages in. The default category should be the same of the page where the user comes from (the only backlink at that moment).

I read that Sylvie is already working on this. Sylvie if you need help please let me know!

I just started exploring the tikiwiki world but at least I can test. And maybe debug a little until I learn enough to be more useful.

Ciao
Carlo


Upcoming Events

1)  18 Apr 2024 14:00 GMT-0000
Tiki Roundtable Meeting
2)  16 May 2024 14:00 GMT-0000
Tiki Roundtable Meeting
3)  20 Jun 2024 14:00 GMT-0000
Tiki Roundtable Meeting
4)  18 Jul 2024 14:00 GMT-0000
Tiki Roundtable Meeting
5)  15 Aug 2024 14:00 GMT-0000
Tiki Roundtable Meeting
6)  19 Sep 2024 14:00 GMT-0000
Tiki Roundtable Meeting
7) 
Tiki birthday
8)  17 Oct 2024 14:00 GMT-0000
Tiki Roundtable Meeting
9)  21 Nov 2024 14:00 GMT-0000
Tiki Roundtable Meeting
10)  19 Dec 2024 14:00 GMT-0000
Tiki Roundtable Meeting