|
Tuesday 04 March 2003 3:38:14 am
> I see. Umm. Well, I have several groups of content all
> separated by SECTIONs, but if that won't work I need
> something that will allow me to:
>
> Designate access to specific USER-GROUPs or ROLEs to
> specific content areas (folders, whatever) on the site.
> Preferably using ROLEs.
>
> Using that information, build the NAV it mentioned directing
> the user to each "section"
>
> How can I interface the data in the user's role for template
> building? Ok, think I got it. In ezp3-rc2 you cannot assign contentobject authorization to users or groups or even roles. This is clearly a shortcoming in ezp3's current authorisation model and I have already issued a bunch of feature requests to the devs on that matter. One possible workaround for this is the following one. However, I do not recommend to use it for the reasons I have outlined lateron. --- Template based access check for content objects ------ After you have created different roles with "content read"-restrictions bound to sections, you can build a default content listing menu for a basic content node, where different subnodes of that node are bound to the distinct content-sections you have defined in your role-model. When you fetch that basic content node in your template as usual with the fetch()-function, in order to create, say a menu of article links, you may use the "can_read", "can_write", "can_edit" permission-control attributes of content objects to decide whether the current site visitor comes to see a content or not:
Use something like the following code to create your menu:
{let menucontents=fetch('content','tree',hash(parent_node_id,$your_basic_content_root_node_id,sort_by,$your_sorting_preference,depth,$your_preferred_tree_depth_to_fetch))}
{section name='Menu' loop=$menucontents}
{section show=$Menu:item.object.can_read}
... template code to display a content link for users who are allowed to read the content due to their section-role-setting ...
{section-else}
... possible template code to create a placeholder for a menuitem that the current user is not allowed to read
{/section}
{/section}
{/let} However, this model of dynamic menu creation has two major disadvantages: 1. It is as slow as every complex template calculation is and becomes even slower with each additional content object to check permissions for. So if you intend to route dozens of articles through the template-oriented permission checker depicted above, your site visitors will easily loose their patience.
2. Template-oriented permission checking is likely to become weired once you activate template caching in order to boost the speed of ezp's rendering fetaure.
The caching of templates will not know which of the menus are designated to which user group, because the permission check IS NOT APPLIED OUTSIDE the template generation process. If it was, it could be applied as routine even before fetching cached templates. With these two rather serious limitations in mind, I recommend that you do not follow that path of page design with dynamic menus that check access permissions in the course of template creation. Instead, I recommend that you achieve a design that allows you to use as many STATIC templates as possible. In your situation, I would seperate the content for different users to different sections (as you already did) and then provide a distinct site access (say 'partner', 'client') with a distinct pagelayout for these site access zones and -- of course -- a require-login flag set in the site.ini-overrides for these zones. Once you users log in to a site access zone, they simply come to see all the content in the section bound to that zone in a static and caching-safe pagelayout_override. Think about it. Regards Volker
|