Re: [Tiki-devel] Tiki9 testing - category admin not showing all thepermissions available

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi Xavi,

 

In the current scheme an edit-structure perm is required. That will grant permission to edit any structure, since edit-structure is a global permission.

 

Can you explain your use-case a bit more?

 

On my side I need to disable the direct object permission inheritance.

The structure pages “travel” through category transitions, which control the accessibility. The root structure pages are protected with direct object permissions, to restrict changes. These direct permissions are only wanted for the structure root pages. Direct object permission inheritance causes problems in this scheme.

So, having an explicit permission to edit/move structure pages, may be better in my case.

However, now that the option to disable it is in place, my use-case is satisfied.

 

I do have some concern about the complexity (as it appears to me) of introducing a new permission for structures.

The usage of structures seems quite diverse. Also note that pages can be allowed to be a part of more than one structure.

 

Personally I don’t really like the idea of having permissions, which override all other permission, set automatically (and quietly) in the background by the system.

So, to remove inheritance of direct object permissions all together, seems like a cleaner solution to me.

 

Note: The update to inheritance of direct object permissions changed when this event occurs from

User having perm Admin-wiki

To

User having perm Admin-wiki or (edit-page + edit-structure)

…in other words non-admins (having edit-page + edit-structure perms) should now experience quiet copying of direct object permissions.

In our discussions this seemed to be wanted by you (and others).

If this turns out not to be the case, maybe the rule for inheriting direct object permissions should be reverted to only apply for Admin-wiki again, until a solution is found? I fear the update may cause surprises (read: bugs) in some systems.

 

Arild

 

 

From: Xavier de Pedro [xavier.depedro@...]
Sent: 21. mai 2012 16:01
To: Tiki developers
Cc: Arild Berg
Subject: Re: [Tiki-devel] Tiki9 testing - category admin not showing all thepermissions available

 

Thanks Arild for the details on this thread, fixes, etc.

I see more clear nowadays that your fix didn't solve the issue of granting permissions to TheUser to move nodes from the definition of other structures in the same site. That's why some perm is needed (imho) to restrict who can move the position of pages from the other structures.

Am I missing anything?

Xavi


On 17/05/12 17:12, Arild Berg wrote:

Geoff,

 

To make the test, maybe this can work….

 

1)      Assign a user (TheUser) to a group TheGroup

2)      For the root page in the structure, you want the user to build and control,

set object permissions edit-page to the group TheGroup.

Give TheGroup the global edit-structure permission

Now TheUser has write access to that particular root node.

If you want to deny write access everywhere else, revoke the edit-page permissions globally.

 

3)      Login as TheUser

4)      Go to the root node

5)      Add Page…this should be possible

A new page should be created. TheUser should have write access and be able to further create structure nodes from the new page.

TheUser cannot create/edit any other pages outside the structure (assuming it’s not granted anywhere else).

 

If this works OK, it should implement a per structure permission scheme, without the need of setting the edit-structure permission to object level.

*However, it won’t work for existing structures, since permission inheritance is done at page create time.*

 

A drawback of the above scheme is that it cannot be combined with categorized permission schemes, since the object permissions will override those permissions. Having an edit-structure at object level, would enable category permissions too.

This may be a cleaner solution, but probably will require the introduction of a new permission, which takes the place of the edit-page + edit-structure combination.

 

If an object level “edit-structure” permission is added, I guess it should apply to the structure views, and not the tools.

(I don’t think the tools can be associated with an object).

 

Edit-structure alone applies to the structure tools. Edit-page alone applies to general wiki pages.

If a (edit-structure-page) permission is introduced, I guess it would have to override edit-page permissions for structure pages.

Or maybe they both must be true?

…it may involve some complexity to add a edit-structure-page permission, with unknown side-effects.

Maybe the object permission inheritance scheme is sufficient?

 

About the fix …

 

The problem you reported, was that the permission check did not consider the edit-structure permission, when displaying “Add Page” in the structure view (if I understood it right). This should now work.

The check looks like: check-permission(edit-page, edit-structure)

 

The old “check-permission” function looked like: check-permission(perm).

Thus only the first parameters is actually interpreted. Edit-structure is the second argument and it was ignored.

PHP quietly ignores this “error”.

 

The fix changed the check-permission function definition to “check-permission”(perm1, perm2, perm3).

Now the edit-structure permission, listed second, is also checked.

 

Arild

 

From: geoff@enmore [geoff@...]
Sent: 16. mai 2012 19:57
To: 'Tiki developers'
Subject: Re: [Tiki-devel] Tiki9 testing - category admin not showing all thepermissions available

 

Arild - the problem is that unless the scope for the edit_structures permission is set to 'object' then you cannot grant this permission on an individual structure page since it is simply not listed in the permissions admin screen. So I think your suggested test below is impossible to do.

 

And I'm not sure that my problem is solved for the same reason, even if an underlying permission check is now done.

 

geoff

 

 

---

From: Arild Berg [mailto:bergar@...
Sent: 16 May 2012 16:15
To: 'Tiki developers'
Subject: Re: [Tiki-devel] Tiki9 testing - category admin not showing all thepermissions available

Hi Xavi,

 

In structures, when creating a new page, the direct object permissions will be inherited for users with either admin permissions or edit-page + edit-structure permissions.

The inherited permissions are copied from the “parent” page.

 

To test… for a user without global editing rights, grant direct permissions on a structure page. (edit-page and edit-structure rights).

When the user creates a new structure page (using “Add Page”), the new page will also be editable for the same user, since the direct permissions are inherited.

Thus a user should be able to edit the page tree, given permissions to a single root page.

 

Note that direct object permissions override all other permissions settings, and that this functionality should be used with care.

In the wiki admin the copying of these direct permissions can be disabled.

 

Hope this helps

 

Note that Geoff’s problem mentioned below is not exactly the same, but is fixed/included in the same commit, due to a change in the underlying permission check function.

 

Arild

 

From: Xavier de Pedro [mailto:xavier.depedro@...
Sent: 16. mai 2012 09:41
To: Tiki developers
Cc: Arild Berg; geoff@...
Subject: Re: [Tiki-devel] Tiki9 testing - category admin not showing all the permissions available

 

Arild, what should be done (if structure permissions are not modified to allow object permissions at structure level, regardless of global permissions on structures), so that a non-admin users can be granted permissions to edit 1 structure, but not all the others...

I'm willing to test, but I don't6 fuly get what is the expected procedure, without object perms on structures, that this behavior can be achieved.

Any pointers appreciated.

Xavi

P.S. I've been pursuing to have permissions on local structures in tiki sites since a few years ago already ... (I'm very concerned with this limitation in tiki already with structures; and imho, this should be achievable without using categories in an optimum tiki implementation)

On 05/05/12 09:38, Arild Berg wrote:

Hi Geoff,

 

The regression/bug you are referring to should have been fixed.

 

The check sent 2 paramaters to the tikilib function user_has_perm_on_object  to verify the access.

However, this function only accepted 1 parameter. The second one, the edit_structure permission, was ignored.

The user_has_perm_on_object  now accepts 3 permissions , and the check should work OK.

Please give it a try.

 

I don’t think it’s correct to put structure permissions at an object level.

 

The same permissions, I believe, are also used when editing the structures in the admin structure panels.

There I am not sure an object applies. Unless we look at the individual structure being worked on (and not on the tools). I guess that could work.

If changed which permission would then limit the access to the tools?

To me it seems best to keep structure permissions global.

 

I hope that you problem case is already solved, and we don’t need to re-work the structure permissions.

 

Arild

 

From: geoff@enmore [geoff@...]
Sent: 5. mai 2012 01:02
To: 'Tiki developers'
Subject: Re: [Tiki-devel] Tiki9 testing - category admin not showing all the permissions available

 

OK - I think I understand, some permissions are 'deemed' to only be global and this is set in lib/userslib.php where 'scope' is set to 'global' for just global/group permissions and 'object' for either category of individual object permissions - but just doing this doesn't mean that the right checks/tests are done throughout the code

 

My specific interest at present is the edit_structures permission which I think should have 'object' 'scope' but is just 'global' at present. The reason for this is a regression/bug I noted on 2nd April

 

WYSIWYCA problem with Structures. If a user does not have the tiki_p_edit_structures permission they should not be able to see the Add page/child tools in the structure bar at the top of the page - but they can. The "tiki-wiki_structure_bar.tpl" template needs to be updated to do a more complete check that the user does have the tiki_p_edit_structures permission for the specific page observing any categorisation, before displaying the Add page/child tools.

 

The specific use case I want to cover is not just whether the user has global permission but also the situation where an individual page within a Structure is categorised and does not allow the user access to the Structure edit tools

 

If no one objects I will change the scope for this permission in trunk so it can be included in categories and then I'll take it from there to try and sort out the checks.

 

cheers

 

geoff

 

 

 

---

From: Louis-Philippe Huberdeau [mailto:lphuberdeau@...
Sent: 04 May 2012 17:05
To: Tiki developers
Subject: Re: [Tiki-devel] Tiki9 testing - category admin not showing all the permissions available

Still has to be tested... changing hte scope does not mean the permission is checked at the right level.

--
LP

On Fri, May 4, 2012 at 12:00 PM, Marc Laporte <marc@...> wrote:

Hi Geoff!

The permissions may not all have the right scope.

Here is an example of how to change:

--- trunk/lib/userslib.php      2012-04-02 01:51:30 UTC (rev 40635)
+++ trunk/lib/userslib.php      2012-04-02 02:02:01 UTC (rev 40636)
@@ -4915,7 +4915,7 @@
                              'type' => 'wiki',
                              'admin' => false,
                              'prefs' => array('flaggedrev_approval'),
-                               'scope' => 'global',
+                               'scope' => 'object',


Thanks!

M ;-)

On Fri, May 4, 2012 at 11:21 AM, Louis-Philippe Huberdeau
<lphuberdeau@...> wrote:
> Hello Geoff,
>
> This is a change that reflects how things really are. The permissions that
> only apply globally are no longer listed along with category or object
> permissions.
>
> --
> LP
>
> On Fri, May 4, 2012 at 10:00 AM, geoff@enmore <geoff@...>
> wrote:
>>
>> Hi - just spotted something odd with the category admin pages where all
>> the various permissions for an individual category can be set for the
>> different Groups.
>>
>> For some reason not all the available permissions are being displayed in
>> the category screen e.g.
>> - in tiki9 r41322 in the wiki section, only 17 permissions are shown but
>> in the global/group permissions there are 22,
>> - in tiki9alpha in the wiki section, only 16 permissions are shown but in
>> the global/group permissions there are 19,
>> - but in a 6.x instance there are 25 permissions and in the global/group
>> permissions there are 25,
>>
>> The wiki setup/features explains the difference between what is shown in
>> the global/group list for the three different instances, but why isn't the
>> category list the same as the global/group list?
>>
>> I've not gone through to see what all the missing permissions are but for
>> example in both the Tiki9 instances the watch_structures and edit_structures
>> permissions are not displayed in the categories screen - but Structures is
>> definitely 'on' in both cases.
>>
>> Is this a bug or something stupid I am doing????
>>
>> cheers
>>
>> geoff
>> ________________________________
>>