forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Batlin" <>
Subject RE: [JIRA] Created: (FOR-385) Profiled access list controlled documents
Date Sun, 19 Dec 2004 11:15:21 GMT
Can someone assign this to me please, as I am virtually done on this. I will
then try to create it as a plugin for 0.7 if I can figure out how to include
custom cocoon.xconf in the project and the blocks jars in the project not in
forrest itself. Many thanks.

-----Original Message-----
From: [] 
Sent: 21 November 2004 21:25
Subject: [JIRA] Created: (FOR-385) Profiled access list controlled documents


  A new issue has been created in JIRA.

View the issue:

Here is an overview of the issue:
        Key: FOR-385
    Summary: Profiled access list controlled documents
       Type: New Feature

     Status: Unassigned
   Priority: Major

    Project: Forrest

   Reporter: Alex Batlin

    Created: Sun, 21 Nov 2004 3:23 PM
    Updated: Sun, 21 Nov 2004 3:23 PM
Environment: Windows XP

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 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 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 sees the link.

Here is the original email thread:

-----Original Message-----
From: Ross Gardler [] 
Sent: 21 November 2004 13:49
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.


This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

View raw message