Loading...
 
Features / Usability

Features / Usability


Users cannot add pages to structures

posts: 12

I am using TikiWiki 5.3 (downloaded today).

I have created a group with a user.
I have not manipulated global permissions.

As admin, I have created a structure.
After having clicked the structure (to be redirected to it) I assigned the above mentioned group all wiki rights (except the last ones which talk about some plug-in-stuff).

The rights I assigned includes
tiki_p_edit_structures
tiki_p_watch_structure

When logging-in with the mentioned user I can access the structure, but when trying to add a page I get an error that I do not have access to edit the page being created (and indeed it is not created).

What am I doing wrong?

posts: 12

Update:
I just found out how it works and how not (and I do not think that this has anything to do with structures at all).

So, I have 3 groups now:

- Business
- Private
- Others

I have 3 pages (actually structures) with names matching the groups name and with some sub-pages:

- Business
- Private
- Other

In each group one testuser exists:

- testbusiness (part of anonymous, registered and business)
- testprivate (part of anonymous, registered and private)
- testother (part of anonymous, registered and others)


The two approaches I made:


a)
When I do not set any global permissions (for no group) and just set object permissions on the above mentioned pages users cannot create new pages within the structure.

Example:
1. No global permissions set, as said.
2. I gave ONLY the group private all wiki permissions (except admin_wiki) on the page private (and its sub-pages).

What does work:
The user testprivate saw the content of the page private and its sub-pages - as intended.
Other users do not see this content - wonderful.

What does NOT work:
The user testprivate cannot create sub-pages underneath the page (the structure) private.


b)
This time I set global permissions.
More precisely, I gave all groups (I assigned permissions to the group registered, the above mentioned groups are sub-groups) all wiki permissions except admin_wiki and then removed particular permissions from concrete objects (pages, structures).

Example:
1. Global permissions said as described above.
2. For the group private I removed all permissions on the pages business and other; for the group business I removed all permissions on the pages private and other and so forth.

What does work:
The user testprivate saw the content of the page private and its sub-pages - as intended.
Other users do not see this content - wonderful.
So, every user does only see what he should see and can now even create sub-pages.


I really do not like the 2nd approach as it is much more work and error prone than the 1st one.

Can anyone explain whether the 2nd approach is the only approach that will work or whether one can get the 1st approach working, too?

Is there maybe a single permission I should set globally to make the 1st approach work?

By the way - this forum feels a bit "dead" - is TikiWiki still alive?

posts: 289 United States
NautilusIII wrote:
By the way - this forum feels a bit "dead" - is TikiWiki still alive?


It's not that Tiki is dead (or the forums), it's that Tiki suffers the same problem as many other websites on the Net; there are 95% lurkers and 5% contributors. Most people come to the forums looking for help but when you only have a small percentage of the user base actually responding it makes for challenging supply versus demand situation.

The other issue is that Tiki is very powerful and highly customizable which is great but this has the unfortunate side-effect of making it much more complex, such that there is quite a steep learning curve often just beyond the reach of those intermediate users not willing or able to invest more time than possibly required to learn about Tiki. This isn't a criticism, just a reality.

In answer to your question, I'm still trying to wrap my head around it, but what about creating categories that match each of your user groups and setting the structure/wiki permissions at the category level then categorizing the structures accordingly?

In general you want your global permissions to be the most broad, giving the maximum access permissible, with categories restricting that access slightly, then object permissions refining that access as a last resort. Generally, at least in my opinion you want to avoid object permissions if at all possible because it can become a maintenance nightmare (it's hard to keep track of all the objects with their own permissions).

posts: 12

Yeah, categories might be a solution as a layer between global and objects permissions.

But it sounds like that starting with most permissions on a global level and reducing permissions stepwise is really the intended way to go, so my 1st approach really could not work, right?

posts: 289 United States

The chain of permissions goes from Object permissions which override Category which override Global permissions. If you have no global permissions, you have no fall-back. To me that is a broken system. There must always be the final answer, even if that answer is no.

In other words if you forget to set object or category permission then what is your Tiki supposed to do? You should always be able to predict exactly what your system is going to do, if you have to guess how it's going to behave then your system is incomplete.

I hope this doesn't sound too preachy. I certainly don't claim to have all the answers, however to my mind you want to think of permissions as from least specific (global, works for most users) to most specific (object, which only for a very specific set of users).

posts: 12

Have you really read what I did?
I set object permissions which should have told Tiki what to do (on that object at least) - actually no need for a fall-back; the fascinating thing is that when I set the SAME permissions as global permissions (and just remove permissions for certain groups on an object basis) things work.

To me "no global permissions" should mean "nothing allowed" and not "something is broken"; adding permissions on object level should then add rights so that more than nothing is allowed.

But as elaborated above this does not work as I would expect it to work.

posts: 289 United States
Yes, I did read what you wrote.

posts: 4656 Japan

I'll try to reproduce your problem when I get time. In the meantime, I hope someone else can confirm things one way or another.

Tiki is very much alive - there's a new release pretty much every six months, with a lot of significant changes and fixes. One reason why these forums are as quiet as they are, I think, is that the people who really know the code are busy coding and rarely visit here. Then, people who have experience with Tiki as users and admins tend to take the code and go, apparently, not coming back to help others much. Anyway, that's my impression. It is a very complex and full-featured project compared to the single-purpose web apps around, so the absence of an active group of "power users" helping out newcomers (there are some exceptions of course) is a big downer.

-- Gary
themes.t.o - zukakakina.com


posts: 19
I have the same issue.

posts: 19
Try assigning tiki_p_edit_structures to the groups which you want to be able to add pages. If it doesn't work when assigned in the category, try assigning it as a global permission (which seems like the wrong way to do it, but it worked for me).

posts: 19
accidental double post, edited out.