Re: [Tiki-devel] Permission bug when creating page from structure

[Xavier de P. <xav...@vh...>]

sorry, no idea about this.
I would say: go ahead with what you consider is needed. Trunk, when 
stable, and after 9.0 is out, backport to 9.x (I will be able to test by 
then, probably, etc)
Cheers
Xavi


On 14/04/12 02:46, Arild Berg wrote:
>
> Hi Xavier,
>
> Thanks for your explanation. I agree that keeping the current status + 
> adding an option is the way to go.
>
> I did some more checking on structures. The table: 
> 'tiki_structure_versions' is defined and empty + it doesn't seem to 
> have any references in the code.
>
> Since it's there it must have served some purpose at one point. Now, 
> it seems redundant.
>
> Does anybody know the history/purpose of this table?
>
> Tiki_structures is the main table for structure pages. A "governing 
> table" for structures (i.e. 1 structure, 1 row) is missing.
>
> This makes it more difficult + messier to add options relating to a 
> structure.
>
> The tiki_structure_versions seems to have the properties of such a 
> table, though with "version handling" in mind.
>
> Adding a "structure governing table" maybe worth investigating a bit 
> more (maybe by re-activating the tiki_structure_versions table)
>
> Arild
>
> *From:*Xavier de Pedro [mailto:xav...@vh...]
> *Sent:* 13. april 2012 18:17
> *To:* Arild Berg
> *Cc:* 'Tiki developers'
> *Subject:* Re: [Tiki-devel] Permission bug when creating page from 
> structure
>
>
>
> On 12/04/12 15:56, Arild Berg wrote:
>
> Hi Xavier,
>
> Thanks for your reply.
>
> You are right, the code makes the page inherit the permissions from 
> the parent page.
>
> However, I am still not clear about why this is needed/wanted.
>
>
> Workspaces (imagine students in a classroom, or workers in a work 
> team, knowing almost nothing about permissions in tiki: they are just 
> told , "write this within your homepage" (structure main page, for 
> instance), and you are fine with permissions. Requesting to write 
> pages who knows where, and have them play with categories, is another 
> level of complexity. Even myself, I need to invest a fair amount of 
> time if I want to play with category permissions... (they are tricky 
> when there are a few groups with different acces levels, and each 
> semester you have to play with them all again, etc).
>
> If we had some Workspaces GUI (user-friendly) which would handle this 
> things transparently to the end user, and easy to setup for a power 
> user (like what we have with Aulawiki mod back in the Tiki1.8-2.0 
> days), then we wouldn't mind if they are handled with categories, 
> perspectives, profiles, datachannels, or whatever new term used by devs).
>
>
> Given that direct object permissions override all other permission 
> setting, it is my opinion that these permissions must be set 
> explicitly and not automatically as it is today.
>
> make it optional
>
> It is possible to auto-assign categories to the structure pages, and 
> use the category permission to control the access.
>
> Changing permission settings in a structure of pages will direct 
> object permissions is a mess. Category permissions are much cleaner.
>
> and with a more steep learning curve also, don't forget that.
>
> To me the inherited object permissions seems like a bug (maybe an 
> ad-hoc solution once upon a time), and an option should not be added 
> to keep the status quo.
>
> I understand what you mean. if you were able to fix the regressions in 
> all sites upgrading to the version with your changes, I would be fine 
> with changing the default setting. But until then, I suggest that you 
> make your change optional, disabled by default, and in your tiki 
> sites, you enable that setting, etc. That's the way of the 3 tiki dev 
> rules, imho...
>
>
> If an option should be included, I assume it should be added to the 
> structure configuration (as a feature for all structures or per 
> structure?)
>
> +1 for "per structure"
>
> Arild
>
>
> Thanks for raising this issue. Structures are very valuable, and imho, 
> they need some more love! (they are getting much better, don't get me 
> wrong...)
>
> cheers
>
> Xavi
>
>
> *From:*Xavier de Pedro [mailto:xav...@vh...]
> *Sent:* 12. april 2012 12:29
> *To:* Tiki developers
> *Cc:* Arild Berg
> *Subject:* Re: [Tiki-devel] Permission bug when creating page from 
> structure
>
> Arild, isn't it for allowing workspace-like behavior: new pages 
> created from users within one structure, will inherit the same 
> permissions as the parent page?
> (if I understood the code/situation properly)
>
> Structures are tricky (and imho, they miss local permission to allow 
> granting permission on single structures only to certain groups of 
> people). They are a key feature in many tiki sites used to deploy 
> knowledge bases within organitzations, with different subgroups of 
> people having different structures of pages, etc., so, in case of 
> doubt, I would make your change optional, and disable by default in 
> new installs or upgrades (to prevent regressions)
>
> My 2 cents.
>
> Xavi
>
> On 11/04/12 16:48, Arild Berg wrote:
>
> Hi,
>
> in Tiki 8.x (and probably later versions, too)
>
> when adding a new page to a structure, direct object permissions will 
> be sometimes be set automatically.
>
> Since direct object permissions override all other permissions, this 
> will break the access control in systems
>
> which rely on category transitions + category permissions.
>
> in tiki-editpage.php the code below is at fault
>
> "
>
> //Criss Holman added the if containing this code of which I don't know 
> the use, but a check before the permissions copy
>
> //is definitely needed in case someone has 
> tiki_p_edit/tiki_p_admin_wiki in a page belonging to a structure. chealer
>
> if ($tikilib->user_has_perm_on_object($user, $_REQUEST["page"],'wiki 
> page', 'tiki_p_admin_wiki', 'tiki_p_admin_categories'))
>
>                 
> $userlib->copy_object_permissions($page_info["pageName"], 
> $_REQUEST["page"],'wiki page');
>
> "
>
> If the check $tikilib->user_has_perm_on_object(...) is true, direct 
> object permissions will be set.
>
> I don't understand why the copying is done.
>
> So, before removing it I would like to check if anybody knows why the 
> code is present.
>
> ¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
>
> Arild Berg
>
>