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.
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.
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.
On Fri, May 4, 2012 at 12:00 PM, Marc Laporte <marc@...> wrote:
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',
On Fri, May 4, 2012 at 11:21 AM, Louis-Philippe Huberdeau
> 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
> On Fri, May 4, 2012 at 10:00 AM, geoff@enmore <geoff@...>
>> 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????
|Free embeddable forum powered by Nabble||Forum Help|