Features / Usability

Features / Usability

Category tiki_p_edit permission are not applied while creating page.

posts: 8311 Israel

I have create a category and set Object Permission to that category so user from a specific group (assigned to the same category) can edit wiki content, create pages, etc.

Can view page/pages (tiki_p_view)
Can edit pages (tiki_p_edit)
Can view wiki history (tiki_p_wiki_view_history)
Can create and edit structures (tiki_p_edit_structures)
Can rename pages (tiki_p_rename)
Can view wiki comments (tiki_p_wiki_view_comments)
Can view source of wiki pages (tiki_p_wiki_view_source)

Seams that the perms are properly applied history, rename, source, edit page are possible. But not creating a page.

If i insert in a page from wiki syntax newpage or from using the Structure strip (add page) i have an error, you don't have permission to edit this page...

I have tried many things but ONLY if i give global permission to write page (all the page, not only categorized pages) it work (of course).

Any idea ????

posts: 8311 Israel

In the file /tiki-editpage.php

Seams the category perm are not checked around the line 146.

If i change if ($tiki_p_edit !== 'y') {
to 'n' it work of course. :-)

posts: 1559


in my mind a normal behaviour.

At the moment you create a page, it is not yet categorised, so category permissions are not yet applied and you cannot edit without general edit perms.

Solution is a rethinking of user/group permission management.

This in my mind is an underestimated topic in our documentation at this time.

So setup tiki_p_edit for all editors and workout all content with category => even public (wiki) content gets a category ... category public.

So if all content is categorised, nobody can edit or view, who is not explecitely permitted

And for uncategorised content you simply set very strict limited visibility tiki_p_view.


you did not set object permissions (as a category is not an object but a category ;-) ) you did set category permissions and apply the category to the object.

you should very rarely use object permissions - especially when you use categories and category permissions - otherwise you will get in trouble by overriding types of permissions and endup not finding where the wrong object permissions block the right category permissions ...

... object permissions can be handy and necessary, but be careful and do not use the mixed up with other sorts of permissions all over the place


posts: 8311 Israel

Hi Torsten,

What you said is not true.

By reading the comment in the code and the documentation this use case has being foreseen and it should work.

In admin group you can set; "Default category assigned to uncategorized objects edited by a user with this default group:" (and of course i have set it).

So the category is known which mean that in my case the perm are set by the moment the user from this group is known even before the page is saved.

In the code of tiki-editpage.php there is a lot of comment and function about "guessing" the under-creation page properties. This as been especially in the case of user adding page via Structures.

Not sure you have check the code but just to give you an idea.

"// This is a new page being created. See if we can guess some of its attributes"

"//Is new page to be inserted into structure?"

"//Page may have been inserted from a structure page view

"// Inherit direct object permissions for pages added to a structure, if the user can edit the structure and the page


The fact that we have a tiki_p_edit perm (create and edit page) in category is also self-explanary. :-)

From what i see a check is missing and the condition on line 146 is preventing the conditions coming afterward about granting perm to a user to edit/create a page. (maybe something around line 1101).

posts: 8311 Israel

About assigning object perm vs global perm vs category perm. I agree as managing perm is a delicate task.

But there are case when you have to assign specific perms to specific users for specific object or branch/section (category) or even feature.

Not a lot of CMS/Wiki can handle such, Tiki Wiki can.

This is why some companies select Tiki Wiki. wink

posts: 3

We are having this problem also.

We want to open up specific pages to be edited by a specific group (and of course higher level editors and admins).

I have tried both categories ans structures but any pages created cannot be edited without manual intervention to create a page with the right category.

posts: 1559

I believe there are methods in Tiki to solve your problem ....

I am thinking now about a special configuration / using certain parameters with the module_quickedit

You can limit visibility of modules per category.

And I think to remember, that you can set a certain default category for the module_quickedit

Have to head off now, but try this — this would be the next thing to look into for me


posts: 8311 Israel

I read you (tks wink ).

So, yes the quick-edit module can be a workaround.

In my case it will make me to change a little the things so i drop structure feature (not part of the module) and instead use "Category" to generate a listing (kind of menu) with the pages added by all the authorized users.

Could be other issues but seams acceptable.

Of course it doesn't make the bug go away !!

Adding page for a user belonging to a group that has right to create page in category and default category for created object is set (same) should work.

posts: 8311 Israel

I found out that it is working just fine on TW6.

Definitely a regression.