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 [mailto: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
> >> ________________________________
> >>
>  
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2176 / Virus Database: 2425/5001 - Release Date: 05/15/12
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2176 / Virus Database: 2425/5001 - Release Date: 05/15/12
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> TikiWiki-devel mailing list
> TikiWiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel