You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by ICM S Op Guest 5 <IC...@icn.siemens.de> on 2001/11/21 19:08:00 UTC
Group, Roles, Permissions
Hi,
I need some informations about groups, roles, permissions in Turbine (Jetspeed).
Is there any documentation available?
Is it still under development or is it already working?
What information will be stored in the DB-Field called OBJECTDATA?
Thanks,
Andreas
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Group, Roles, Permissions
Posted by David Sean Taylor <da...@bluesunrise.com>.
I believe that this is already working in Jetspeed for Portlet security if
> I'm not mistaken. I thought David had it working.
Ive extended TurbineSecurity with methods for portlet security, and wrote a
few portlets to manage users/groups/roles.
You can have a look at the security portlets by logging on to the default
Jetspeed configuration as admin/jetspeed, and then click on the 'Security'
tab.
I try to keep the latest version of jetspeed running here:
http://www.bluesunrise.com/jetspeed/
David
----- Original Message -----
From: "Jason van Zyl" <jv...@zenplex.com>
To: "Turbine Users List" <tu...@jakarta.apache.org>
Sent: Wednesday, November 21, 2001 10:20 AM
Subject: Re: Group, Roles, Permissions
> On 11/21/01 1:08 PM, "ICM S Op Guest 5" <IC...@icn.siemens.de>
> wrote:
>
> > Hi,
> >
> > I need some informations about groups, roles, permissions in Turbine
> > (Jetspeed).
> > Is there any documentation available?
> > Is it still under development or is it already working?
>
> Fully working, there is flux a reference implementation and some fellows
are
> working on a new interface over in Scarab land and it's looking good.
> Hopefully it will find it's way back into Turbine in general and than
> Jetspeed can use it as well.
>
> > What information will be stored in the DB-Field called OBJECTDATA?
>
> This field is going away because it causes problem due to blobs and can
> produce some serious limitations when searching or indexing is required.
If
> you need to add additional information for your user system look at the
> extended-user howto. This will generally be a lot easier in turbine 2.x
but
> there is a system in place that works.
>
> I believe that this is already working in Jetspeed for Portlet security if
> I'm not mistaken. I thought David had it working.
>
> > Thanks,
> >
> > Andreas
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
v3 compatibility [was: Group, Roles, Permissions]
Posted by Jonathan Carlson <jo...@yahoo.com>.
I want to say that I have shared Dave's frustration.
Maybe what Dave is talking about would be a very obvious section on the
web site detailing "how to write code in 2.x that will more easily port
to 3.x". It's something that new users really need to know about and
the web site is the first place they will look.
Ideally, it would be on this page which is practically empty right now:
========= http://jakarta.apache.org/turbine/turbine-3/index.html
=============
I happened to run into something about the importance of using pull
tools in a discussion list, but like Dave, I could easily have missed
that since the web site has pull information buried and even then
doesn't discuss pull's importance to version 3 compatibility.
If I knew Turbine better I'd write this stuff myself for you, but I don't.
Jonathan
joncrlsn@users.sf.net
Jason van Zyl wrote:
>On 11/24/01 10:47 AM, "Dave Everson" <dj...@mygolftrac.com> wrote:
>
>>Is there a place where the main developers of Turbine are posting upcoming
>>changes and/or announcements about future releases of Turbine?
>>
>
>The developers list is usually where we chat about future changes.
>
>>There really
>>should be.
>>
>
>There is also a proposals link from the 2.x documentation page which states
>a lot of the plans we have. We also discuss future changes in IRC to which
>the location has been posted many times and anyone is free to join in.
>
>>I get really concerned when I find sentences such as "This field
>>[OBJECTDATA in Turbine_User] is going away because it causes problem due to
>>blobs and can produce some serious limitations when searching or indexing
>>is required".
>>
>
>The removal of this from the standard schema has been discussed numerous
>times, it is in the security service proposal and the OBJECTDATA will not be
>removed from the released version as per our deprecation rules. These
>changes are slated for 3.x which will certainly have API changes.
>
>
>>I am deep in the middle of delveoping a Turbine application and have used
>>this feature because I needed a few additional attributes for each user and
>>did not want to go through the hassle of extending Turbine_User.
>>
>
>Fair enough, this isn't going to change in the 2.x series of releases.
>
>>Now I read
>>this and need to go back through my project and stop using OBJECTDATA
>>because it will not longer exist in future releases.
>>
>
>Will not exist in the standard schema, but you can easily put it back in
>yourself if that's how you wish to add extra user attributes. We've
>generally agreed it's a bad approach and there will be a flexible way using
>Torque to generate a user schema, part of that schema can be an OBJECTDATA
>field if you so desire.
>
> > The main developers should be more proactive in communicating to the
>
>>community using the framework what changes are coming up so that we can
>>prepare for them and if possible minimize the impact of such changes.
>>
>
>We are still working on the next version and many things have yet to be
>worked out. When the next version is close to ready there will be a clear
>path. There is even a migrator that is part of the TDK that will be
>available for users moving forward. This has also been discussed on the
>list.
>
>The main project I work on is a 2.x application (Tambora) so I am very
>concerned with ease in moving forward between versions because Tambora
>developers are going to have to do this. I have spent a great deal of time
>trying to decouple large parts of Turbine so future use and maintenance is
>easier, but I am also trying to provide mechanisms to run these old and new
>methodologies side by side so that moving forward can be done in stages.
>
>>While
>>the above change is not all that complex for me to overcome, I wonder what
>>other advertised features of Turbine will just be yanked at some point
>>without no communication.
>>
>
>Before Turbine was release, things changed a lot but since the release we
>have been very careful. You're above statement is completely inaccurate and
>way off base. The proposal which states the change to the feature you are
>worried about has been in documented form for a long time:
>
>http://jakarta.apache.org/turbine/turbine-2/proposals/security-service.html
>
>
>>While I try to read most of the posts made to the mailing list, I can't
>>possibly keep up with each and every one.
>>
>
>Well, I would try the website at least as a start. Than you would have seen
>the reference to the particular item that seems to concern you.
>
>>I consider myself lucky that I
>>spotted this change. I think having a page on the Turbine site that points
>>out major upcoming changes would be great.
>>
>
>We fully plan too, there are many notes in CVS and the proposals outline
>many of them. We do what we can but we don't have anything like monthly or
>quarterly bulletins (yet). But you can always ask questions on the user
>list, I admittedly can get frustrated but it is not often that I won't try
>to answer a question by a concerned user.
>
>
>>I can't recall the last time one of the main developers sent out an email to
>>the mailing list to say here are some upcoming changes,
>>
>
>The content of the proposals hasn't changed much and they are in public view
>on the website. When the next version of Turbine is close to available tools
>and documents will be made available to help users. But I would like to add
>that Turbine has always been a tool to make life for developers easier and
>as a user of Turbine you are really a developer and therefore have every
>right to put your hand up and ask what's going on and contribute toward its
>new direction.
>
>A lot of time the developers who use Turbine and the prime users and we
>often decide the direction and users often get what we decide. You are
>completely free to join in the discussion, and as you point out a lot of
>ideas are not passed up to the users list and I will try to change that but
>we are not BEA and I'm not a customer service department. As much as I can
>try to change patterns that have been established in the Turbine community
>the onus is on you to make those changes happen.
>
>If you are volunteering to help communicate in a more professional fashion
>with the user community than I call you on my own dime and explain anything
>you want to know so that you can pass it on to the user community. I would
>love to have a user community liason. Are you volunteering?
>
>>what do you the
>>users of the think of the changes. I have discovered most of these changes
>>in responses to questions from the users.
>>
>>I think the Turbine framework is a great framework, but we all have to keep
>>in mind that people are using the framework in production systems and making
>>changes without communication may drive people away from the framework
>>because it will be too hard to maintain the applications that they develop
>>using the framework.
>>
>
>We can only do what we can do. We are trying to be more thorough with
>changes that are made
>(ex.http://jakarta.apache.org/turbine/torque/changes.html) but we need help.
>
>
>>I know changes will be made, just *please* keep us informed.
>>
>
>Always intended to.
>
>
>>----- Original Message -----
>>From: "Jason van Zyl" <jv...@zenplex.com>
>>To: "Turbine Users List" <tu...@jakarta.apache.org>
>>Sent: Wednesday, November 21, 2001 12:20 PM
>>Subject: Re: Group, Roles, Permissions
>>
>>
>>>On 11/21/01 1:08 PM, "ICM S Op Guest 5" <IC...@icn.siemens.de>
>>>wrote:
>>>
>>>>Hi,
>>>>
>>>>I need some informations about groups, roles, permissions in Turbine
>>>>(Jetspeed).
>>>>Is there any documentation available?
>>>>Is it still under development or is it already working?
>>>>
>>>Fully working, there is flux a reference implementation and some fellows
>>>
>>are
>>
>>>working on a new interface over in Scarab land and it's looking good.
>>>Hopefully it will find it's way back into Turbine in general and than
>>>Jetspeed can use it as well.
>>>
>>>>What information will be stored in the DB-Field called OBJECTDATA?
>>>>
>>>This field is going away because it causes problem due to blobs and can
>>>produce some serious limitations when searching or indexing is required.
>>>
>>If
>>
>>>you need to add additional information for your user system look at the
>>>extended-user howto. This will generally be a lot easier in turbine 2.x
>>>
>>but
>>
>>>there is a system in place that works.
>>>
>>>I believe that this is already working in Jetspeed for Portlet security if
>>>I'm not mistaken. I thought David had it working.
>>>
>>>>Thanks,
>>>>
>>>>Andreas
>>>>
>>>>--
>>>>To unsubscribe, e-mail:
>>>>
>><ma...@jakarta.apache.org>
>>
>>>>For additional commands, e-mail:
>>>>
>><ma...@jakarta.apache.org>
>>
>>>--
>>>
>>>jvz.
>>>
>>>Jason van Zyl
>>>
>>>http://tambora.zenplex.org
>>>http://jakarta.apache.org/turbine
>>>http://jakarta.apache.org/velocity
>>>http://jakarta.apache.org/alexandria
>>>http://jakarta.apache.org/commons
>>>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>>
>><ma...@jakarta.apache.org>
>>
>>>For additional commands, e-mail:
>>>
>><ma...@jakarta.apache.org>
>>
>>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Group, Roles, Permissions
Posted by Jason van Zyl <jv...@zenplex.com>.
On 11/24/01 10:47 AM, "Dave Everson" <dj...@mygolftrac.com> wrote:
> Is there a place where the main developers of Turbine are posting upcoming
> changes and/or announcements about future releases of Turbine?
The developers list is usually where we chat about future changes.
> There really
> should be.
There is also a proposals link from the 2.x documentation page which states
a lot of the plans we have. We also discuss future changes in IRC to which
the location has been posted many times and anyone is free to join in.
> I get really concerned when I find sentences such as "This field
> [OBJECTDATA in Turbine_User] is going away because it causes problem due to
> blobs and can produce some serious limitations when searching or indexing
> is required".
The removal of this from the standard schema has been discussed numerous
times, it is in the security service proposal and the OBJECTDATA will not be
removed from the released version as per our deprecation rules. These
changes are slated for 3.x which will certainly have API changes.
> I am deep in the middle of delveoping a Turbine application and have used
> this feature because I needed a few additional attributes for each user and
> did not want to go through the hassle of extending Turbine_User.
Fair enough, this isn't going to change in the 2.x series of releases.
> Now I read
> this and need to go back through my project and stop using OBJECTDATA
> because it will not longer exist in future releases.
Will not exist in the standard schema, but you can easily put it back in
yourself if that's how you wish to add extra user attributes. We've
generally agreed it's a bad approach and there will be a flexible way using
Torque to generate a user schema, part of that schema can be an OBJECTDATA
field if you so desire.
> The main developers should be more proactive in communicating to the
> community using the framework what changes are coming up so that we can
> prepare for them and if possible minimize the impact of such changes.
We are still working on the next version and many things have yet to be
worked out. When the next version is close to ready there will be a clear
path. There is even a migrator that is part of the TDK that will be
available for users moving forward. This has also been discussed on the
list.
The main project I work on is a 2.x application (Tambora) so I am very
concerned with ease in moving forward between versions because Tambora
developers are going to have to do this. I have spent a great deal of time
trying to decouple large parts of Turbine so future use and maintenance is
easier, but I am also trying to provide mechanisms to run these old and new
methodologies side by side so that moving forward can be done in stages.
> While
> the above change is not all that complex for me to overcome, I wonder what
> other advertised features of Turbine will just be yanked at some point
> without no communication.
Before Turbine was release, things changed a lot but since the release we
have been very careful. You're above statement is completely inaccurate and
way off base. The proposal which states the change to the feature you are
worried about has been in documented form for a long time:
http://jakarta.apache.org/turbine/turbine-2/proposals/security-service.html
> While I try to read most of the posts made to the mailing list, I can't
> possibly keep up with each and every one.
Well, I would try the website at least as a start. Than you would have seen
the reference to the particular item that seems to concern you.
> I consider myself lucky that I
> spotted this change. I think having a page on the Turbine site that points
> out major upcoming changes would be great.
We fully plan too, there are many notes in CVS and the proposals outline
many of them. We do what we can but we don't have anything like monthly or
quarterly bulletins (yet). But you can always ask questions on the user
list, I admittedly can get frustrated but it is not often that I won't try
to answer a question by a concerned user.
> I can't recall the last time one of the main developers sent out an email to
> the mailing list to say here are some upcoming changes,
The content of the proposals hasn't changed much and they are in public view
on the website. When the next version of Turbine is close to available tools
and documents will be made available to help users. But I would like to add
that Turbine has always been a tool to make life for developers easier and
as a user of Turbine you are really a developer and therefore have every
right to put your hand up and ask what's going on and contribute toward its
new direction.
A lot of time the developers who use Turbine and the prime users and we
often decide the direction and users often get what we decide. You are
completely free to join in the discussion, and as you point out a lot of
ideas are not passed up to the users list and I will try to change that but
we are not BEA and I'm not a customer service department. As much as I can
try to change patterns that have been established in the Turbine community
the onus is on you to make those changes happen.
If you are volunteering to help communicate in a more professional fashion
with the user community than I call you on my own dime and explain anything
you want to know so that you can pass it on to the user community. I would
love to have a user community liason. Are you volunteering?
> what do you the
> users of the think of the changes. I have discovered most of these changes
> in responses to questions from the users.
>
> I think the Turbine framework is a great framework, but we all have to keep
> in mind that people are using the framework in production systems and making
> changes without communication may drive people away from the framework
> because it will be too hard to maintain the applications that they develop
> using the framework.
We can only do what we can do. We are trying to be more thorough with
changes that are made
(ex.http://jakarta.apache.org/turbine/torque/changes.html) but we need help.
> I know changes will be made, just *please* keep us informed.
Always intended to.
> ----- Original Message -----
> From: "Jason van Zyl" <jv...@zenplex.com>
> To: "Turbine Users List" <tu...@jakarta.apache.org>
> Sent: Wednesday, November 21, 2001 12:20 PM
> Subject: Re: Group, Roles, Permissions
>
>
>> On 11/21/01 1:08 PM, "ICM S Op Guest 5" <IC...@icn.siemens.de>
>> wrote:
>>
>>> Hi,
>>>
>>> I need some informations about groups, roles, permissions in Turbine
>>> (Jetspeed).
>>> Is there any documentation available?
>>> Is it still under development or is it already working?
>>
>> Fully working, there is flux a reference implementation and some fellows
> are
>> working on a new interface over in Scarab land and it's looking good.
>> Hopefully it will find it's way back into Turbine in general and than
>> Jetspeed can use it as well.
>>
>>> What information will be stored in the DB-Field called OBJECTDATA?
>>
>> This field is going away because it causes problem due to blobs and can
>> produce some serious limitations when searching or indexing is required.
> If
>> you need to add additional information for your user system look at the
>> extended-user howto. This will generally be a lot easier in turbine 2.x
> but
>> there is a system in place that works.
>>
>> I believe that this is already working in Jetspeed for Portlet security if
>> I'm not mistaken. I thought David had it working.
>>
>>> Thanks,
>>>
>>> Andreas
>>>
>>> --
>>> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>>
>> --
>>
>> jvz.
>>
>> Jason van Zyl
>>
>> http://tambora.zenplex.org
>> http://jakarta.apache.org/turbine
>> http://jakarta.apache.org/velocity
>> http://jakarta.apache.org/alexandria
>> http://jakarta.apache.org/commons
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>>
>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Group, Roles, Permissions
Posted by Dave Everson <dj...@mygolftrac.com>.
Is there a place where the main developers of Turbine are posting upcoming
changes and/or announcements about future releases of Turbine? There really
should be. I get really concerned when I find sentences such as "This field
[OBJECTDATA in Turbine_User] is going away because it causes problem due to
blobs and can produce some serious limitations when searching or indexing
is required".
I am deep in the middle of delveoping a Turbine application and have used
this feature because I needed a few additional attributes for each user and
did not want to go through the hassle of extending Turbine_User. Now I read
this and need to go back through my project and stop using OBJECTDATA
because it will not longer exist in future releases.
The main developers should be more proactive in communicating to the
community using the framework what changes are coming up so that we can
prepare for them and if possible minimize the impact of such changes. While
the above change is not all that complex for me to overcome, I wonder what
other advertised features of Turbine will just be yanked at some point
without no communication.
While I try to read most of the posts made to the mailing list, I can't
possibly keep up with each and every one. I consider myself lucky that I
spotted this change. I think having a page on the Turbine site that points
out major upcoming changes would be great.
I can't recall the last time one of the main developers sent out an email to
the mailing list to say here are some upcoming changes, what do you the
users of the think of the changes. I have discovered most of these changes
in responses to questions from the users.
I think the Turbine framework is a great framework, but we all have to keep
in mind that people are using the framework in production systems and making
changes without communication may drive people away from the framework
because it will be too hard to maintain the applications that they develop
using the framework.
I know changes will be made, just *please* keep us informed.
----- Original Message -----
From: "Jason van Zyl" <jv...@zenplex.com>
To: "Turbine Users List" <tu...@jakarta.apache.org>
Sent: Wednesday, November 21, 2001 12:20 PM
Subject: Re: Group, Roles, Permissions
> On 11/21/01 1:08 PM, "ICM S Op Guest 5" <IC...@icn.siemens.de>
> wrote:
>
> > Hi,
> >
> > I need some informations about groups, roles, permissions in Turbine
> > (Jetspeed).
> > Is there any documentation available?
> > Is it still under development or is it already working?
>
> Fully working, there is flux a reference implementation and some fellows
are
> working on a new interface over in Scarab land and it's looking good.
> Hopefully it will find it's way back into Turbine in general and than
> Jetspeed can use it as well.
>
> > What information will be stored in the DB-Field called OBJECTDATA?
>
> This field is going away because it causes problem due to blobs and can
> produce some serious limitations when searching or indexing is required.
If
> you need to add additional information for your user system look at the
> extended-user howto. This will generally be a lot easier in turbine 2.x
but
> there is a system in place that works.
>
> I believe that this is already working in Jetspeed for Portlet security if
> I'm not mistaken. I thought David had it working.
>
> > Thanks,
> >
> > Andreas
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Group, Roles, Permissions
Posted by Jason van Zyl <jv...@zenplex.com>.
On 11/21/01 1:08 PM, "ICM S Op Guest 5" <IC...@icn.siemens.de>
wrote:
> Hi,
>
> I need some informations about groups, roles, permissions in Turbine
> (Jetspeed).
> Is there any documentation available?
> Is it still under development or is it already working?
Fully working, there is flux a reference implementation and some fellows are
working on a new interface over in Scarab land and it's looking good.
Hopefully it will find it's way back into Turbine in general and than
Jetspeed can use it as well.
> What information will be stored in the DB-Field called OBJECTDATA?
This field is going away because it causes problem due to blobs and can
produce some serious limitations when searching or indexing is required. If
you need to add additional information for your user system look at the
extended-user howto. This will generally be a lot easier in turbine 2.x but
there is a system in place that works.
I believe that this is already working in Jetspeed for Portlet security if
I'm not mistaken. I thought David had it working.
> Thanks,
>
> Andreas
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>