Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: 
 <15541284.1103454869131.JavaMail.jettyjira@strider.outerthought.net>
Date: Sun, 19 Dec 2004 05:14:29 -0600 (CST)
From: issues@cocoondev.org
To: dev@forrest.apache.org
Subject: [JIRA] Commented: (FOR-385) Profiled access list controlled documents
In-Reply-To: 
 <22117105.1101072290430.JavaMail.jettyjira@strider.outerthought.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The following comment has been added to this issue:

     Author: Alex Batlin
    Created: Sun, 19 Dec 2004 5:13 AM
       Body:
can someome please assign this to me please, I am virtually done this. see =
http://www.batlin.com/devland/xmlpub/profiling.html.
---------------------------------------------------------------------
View this comment:
  http://issues.cocoondev.org//browse/FOR-385?page=3Dcomments#action_11951

---------------------------------------------------------------------
View the issue:
  http://issues.cocoondev.org//browse/FOR-385

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
 Components:=20
             Compile
   Versions:
             HEAD

   Assignee:=20
   Reporter: Alex Batlin

    Created: Sun, 21 Nov 2004 3:23 PM
    Updated: Sun, 19 Dec 2004 5:13 AM
Environment: Windows XP

Description:
With DocBook, I am able to specify element roles. DocBook profiling XSLs ca=
n then be used to produce documents based on say a user profile. This is ve=
ry 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 l=
ogin feature, user to role/group/any-other-profile mapping feature (in effe=
ct 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 t=
o any user (DocBook role attribute =3D "user;support") and one that is appl=
icable to just support staff (attribute=3D"support").=20
2. a mapping file should exist that maps say guest and joe.user to user rol=
es, 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 st=
aff, so a new attribute is required in sites and tabs.xml files, say role t=
o again provide profiling.
2. so when joe.user views the website, another-tool.html|pdf link is not ev=
en presented, but joe.support sees the link.


Here is the original email thread:

-----Original Message-----
From: Ross Gardler [mailto:rgardler@apache.org]=20
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=C3=B3:
>=20
>>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.
>=20
>=20
> No, not AFAIK, but it should be quite easy.
>=20
> 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.
>=20
> 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
>=20
> Can you open an enhancement issue and add this to it. This way it will no=
t get lost.

There are a number of authorisation blocks in Cocoon. Take a look at the=20
Cocoon docs and their wiki for examples. If you fancy having a go at=20
implementing this before it reaches the top of Throsten's ToDo list we=20
will be happy to advise on the best approach.

Ross


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.cocoondev.org//secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira