forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [JIRA] Commented: (FOR-385) Profiled access list controlled documents
Date Sun, 19 Dec 2004 11:14:29 GMT
The following comment has been added to this issue:

     Author: Alex Batlin
    Created: Sun, 19 Dec 2004 5:13 AM
can someome please assign this to me please, I am virtually done this. see
View this comment:

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, 19 Dec 2004 5:13 AM
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