[jira] Commented: (FOR-385) Profiled access list controlled documents

["Brian M Dube (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FOR-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786790#action_12786790 ] 

Brian M Dube commented on FOR-385:
----------------------------------

The locations have changed, but the information is still around:

http://www.batlin.com/forrest/profiling.html

http://www.batlin.com/forrest/blocks.html

> Profiled access list controlled documents
> -----------------------------------------
>
>                 Key: FOR-385
>                 URL: https://issues.apache.org/jira/browse/FOR-385
>             Project: Forrest
>          Issue Type: New Feature
>          Components: Compile
>    Affects Versions: 0.7
>         Environment: Windows XP
>            Reporter: Alex Batlin
>
> With DocBook, I am able to specify element roles. DocBook profiling XSLs can then be used to produce documents based on say a user profile. This is very valuable if you provide a website to both users and support staff as you can generate a version of the document suitable for each user role profile.
> It would be great, if forrest can be extended with user name and password login feature, user to role/group/any-other-profile mapping feature (in effect access control) and profile-based document generation (for both content documents and tabs|site.xmls).
> Here is a content use-case:
> 1. a some-tool.xml DocBook document contains two sections, one applicable to any user (DocBook role attribute = "user;support") and one that is applicable to just support staff (attribute="support"). 
> 2. a mapping file should exist that maps say guest and joe.user to user roles, whilst joe.support is mapped to support role.
> 3. when guest or joe.user want to view some-tool.html or .pdf file, the xml file is profiled and only section 1 is included in the output, whilst when joe.support views the same document, section 1 and 2 are included.
> Here is a navigation use-case (using concepts from previos use case):
> 1. another-tool.xml DocBook document should only be seen by support role staff, so a new attribute is required in sites and tabs.xml files, say role to again provide profiling.
> 2. so when joe.user views the website, another-tool.html|pdf link is not even presented, but joe.support sees the link.
> Here is the original email thread:
> -----Original Message-----
> From: Ross Gardler [mailto:rgardler@apache.org] 
> Sent: 21 November 2004 13:49
> To: dev@forrest.apache.org
> Subject: Re: Dynamic or Static Access Control Lists
> Thorsten Scherler wrote:
> > El dom, 21-11-2004 a las 09:13, Alex Batlin escribió:
> > 
> >>Has anyone configured Forrest to allow user to provide userid and
> >>password, and then generated documents based on their role/group.
> >>Document elements can then be tagged with role/group. I am thinking of
> >>the way profiling is done in DocCook.
> > 
> > 
> > No, not AFAIK, but it should be quite easy.
> > 
> > I will need auth as well pretty soon for profiling. You can either beat
> > me by sending a patch or hang in there and wait (I guess end of the
> > year) till I implemend it.
> > 
> > Basicly you have to do the following for auth, protected docs and
> > profiling:
> > 1) create a dir where the protected docs go
> > 2) create a auth pipeline where you start the session
> > 3) add profiling to the session in your profiling
> > 4) change your skin pipelines to display the profiled content
> > 
> > Can you open an enhancement issue and add this to it. This way it will not get lost.
> There are a number of authorisation blocks in Cocoon. Take a look at the 
> Cocoon docs and their wiki for examples. If you fancy having a go at 
> implementing this before it reaches the top of Throsten's ToDo list we 
> will be happy to advise on the best approach.
> Ross

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.