RE: Psml management
Yes, that sounds really promising, it would have circumvented our need to override the createDefaultPsml() method with Seawave-specific logic. I don't yet have any specific suggestions as to how to work the integration of multiple psml files sounds like a really interesting problem & seems like it could be applied to all sorts of psml related issues! But, our more significant problem at this point is the coupling of portet settings with the psml, which wouldn't be solved by the enhanced role-based psml. I'm not sure that it suffice to provide a link that said something to the effect of, "Click here to upgrade your portal to the newest version... warning, all your settings will be lost!" It would be much better to store the parameters/settings outside of psml. Haven't really thought this through, but if I could decouple user settings from the psml files in a way that would be backwards-compatible, would this system have a chance of making it into a future jetspeed release as a replacement for psml-based settings management? -Matthew Forsyth seawave.com --- Mark Orciuch <[EMAIL PROTECTED]> wrote: > Matthew and Stefan, > > You have brought some good points to discussion > table. You are right that it > isn't very practical (or secure) for the users to > assign their own roles. In > most environments, it would be an administrative > function to assign any > additional user roles. Even if particular portal > uses self-registration > process, the admin would still be responsible for > customizing user roles. > > I am currently working on enhancing the > role-based-psml (see > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11735). > The goal is to > create initial user profile (psml) based on the > roles the user is a member > of. On first login, the profiler will aggregate > profiles from each role to > create a single profile. There will also be a > feature for the user to reset > their profile to default. This, I believe, may > address the issue with what > happens when role profile gets updated - the reset > will recreate the user > profile and bring in any new content (customizations > will be lost, of > course). > > I have implemented the basic process. One remaining > feature is the ability > to handle variety of different layouts. For example, > one role profile may be > tab based, another may consist of a single control, > and yet another may be a > single menu control. How to combine these to create > a meaningful profile? My > thought is to "stack" all tab based profiles and put > other types of profiles > in their own tabs. > > If this is something that may fit into your > requirements, feel free to > provide any comments or suggestions (please use > Bugzilla to post any). > Thanks! > > Best regards, > > Mark C. Orciuch > Next Generation Solutions, Ltd. > e-Mail: [EMAIL PROTECTED] > web: http://www.ngsltd.com > > > > -Original Message- > > From: Matthew Forsyth > [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, August 29, 2002 3:21 AM > > To: Jetspeed Users List; [EMAIL PROTECTED] > > Subject: Re: Psml management > > > > > > Good questions... strictly out-of the box > > role-based-psml also wouldn't work for us for the > same > > reason, some users have more than one role. I > have > > some custom logic that only looks at the > particular > > roles which are associated with a "layout type"... > in > > the database these roles aren't differentiated > from > > other roles in any way. > > > > The question of users getting to chose their own > role > > doesn't apply to us; in fact users can't even > directly > > sign themselves up to jetspeed. Their jetspeed > > account only gets created in response to an > external > > process which knows which role they are supposed > to > > be. > > > > -matt > > > > > > --- Stefan Kuhn <[EMAIL PROTECTED]> wrote: > > > Hi Metthew, > > > I was thinking about giving psml to users > depending > > > on the role as well, but > > > I came to the conclusion that this doesn't make > > > sense because: When people > > > subscribe (i. e. create a new account) they get > one > > > specified role anyway. Or > > > do you leave to visitors to choose which role > they > > > want to have ? But then, > > > when roles mean security restrictions, your > securtiy > > > is gone, because people > > > can choose their role freely. So I thought it > would > > > be better to have
RE: Psml management
Matthew and Stefan, You have brought some good points to discussion table. You are right that it isn't very practical (or secure) for the users to assign their own roles. In most environments, it would be an administrative function to assign any additional user roles. Even if particular portal uses self-registration process, the admin would still be responsible for customizing user roles. I am currently working on enhancing the role-based-psml (see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11735). The goal is to create initial user profile (psml) based on the roles the user is a member of. On first login, the profiler will aggregate profiles from each role to create a single profile. There will also be a feature for the user to reset their profile to default. This, I believe, may address the issue with what happens when role profile gets updated - the reset will recreate the user profile and bring in any new content (customizations will be lost, of course). I have implemented the basic process. One remaining feature is the ability to handle variety of different layouts. For example, one role profile may be tab based, another may consist of a single control, and yet another may be a single menu control. How to combine these to create a meaningful profile? My thought is to "stack" all tab based profiles and put other types of profiles in their own tabs. If this is something that may fit into your requirements, feel free to provide any comments or suggestions (please use Bugzilla to post any). Thanks! Best regards, Mark C. Orciuch Next Generation Solutions, Ltd. e-Mail: [EMAIL PROTECTED] web: http://www.ngsltd.com > -Original Message- > From: Matthew Forsyth [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 29, 2002 3:21 AM > To: Jetspeed Users List; [EMAIL PROTECTED] > Subject: Re: Psml management > > > Good questions... strictly out-of the box > role-based-psml also wouldn't work for us for the same > reason, some users have more than one role. I have > some custom logic that only looks at the particular > roles which are associated with a "layout type"... in > the database these roles aren't differentiated from > other roles in any way. > > The question of users getting to chose their own role > doesn't apply to us; in fact users can't even directly > sign themselves up to jetspeed. Their jetspeed > account only gets created in response to an external > process which knows which role they are supposed to > be. > > -matt > > > --- Stefan Kuhn <[EMAIL PROTECTED]> wrote: > > Hi Metthew, > > I was thinking about giving psml to users depending > > on the role as well, but > > I came to the conclusion that this doesn't make > > sense because: When people > > subscribe (i. e. create a new account) they get one > > specified role anyway. Or > > do you leave to visitors to choose which role they > > want to have ? But then, > > when roles mean security restrictions, your securtiy > > is gone, because people > > can choose their role freely. So I thought it would > > be better to have the > > assignment of psmls if the administrator gives roles > > to users. > > One more problem: What to do if the user has got > > multiple roles - which psml > > take then ? Do you know what the built-in role-based > > psml does in such a case > > ? > > Thanks for your answers and sorry for asking > > questions instead of helping you. > > Stefan > > > > Am Mittwoch, 28. August 2002 23:55 schrieben Sie: > > > Here are my experiences with the jetspeed psml > > > management system. I've had to change a couple > > things > > > in ways which somebody else might find useful > > (please > > > let me know if so!) Also, I am discovering that I > > may > > > have a (hopefully reconcilable) philosophical > > problem > > > with PSML. > > > > > > Before I begin, our portal (still in development > > > stage) can be seen at > > > > > > http://nurse.ri.seawave.com:8180/portal/portal > > > > > > You can log in using "testcrew/password". > > > > > > > > > We don't plan on letting our users customize their > > > portal pages at all in terms of the layout, > > presence > > > or absence of certain portlets. However, we need > > to > > > give them ways to customize attributes of their > > > existing portlets. > > > > > > We also need to service more than one TYPE of > > user, > > > each with a different pre-defined set of panes and > > > portlets. > > > > >
RE: Psml management
A few comments on the questions raised: - the current PSML system has indeed a known limitation when you try to centrally manage changes to user profiles without impacting their customized preferences. I submitted a proposal on an updated PSML structure to fix this issue about 1,5 year ago but we never came around to fix it as it implies extensive changes and may possibly break compatibility with current installations. Additionally, David has added recently a "ref" attribute in the PSML markup to tackle this issue differently. Using this approach it should be possible to leverage the layout while still keeping the customized attributes per user. Unfortunately, as far as I know it's still a work in progress. - about your requirements: if I understand correctly your need, you want to give the users the ability to customize their portlets but not to chose them or modify their layout. In Jetspeed terms, you want the user to be able to customize their Portlets but not their PortletSets. To do this the easiest way is simply to remove or hide the ability to customize them ! * copy the WEB-INF\templates\vm\controls\html\jetspeed-tab.vm to a new file (like jetspeed-tab-nocustomize.vm) and edit it to remove the customize links * change the WEB-INF\conf\controls.xreg registry to use your modified template instead of the default one. You have now hidden the feature, if you want to remove it completely : * modify the Customize action (org.apache.jetspeed.modules.actions.controls.Customize) to change the last test from: if (found!=null) to if ((found!=null)&&(!(found instanceof PortletSet))) recompile and redeploy and you're set. If you're really paranoid you can also remove the following action: - org.apache.jetspeed.modules.actions.portlets.CustomizeSet Remember that you're dealing with an open source system, if you don't like the rules set by the system, remove them ! We tried to make it easy for you to do so and it's much simpler than trying to add new rules or develp very generic ones. > -Message d'origine- > De : Matthew Forsyth [mailto:[EMAIL PROTECTED]] > Envoyé : jeudi 29 août 2002 10:21 > À : Jetspeed Users List; [EMAIL PROTECTED] > Objet : Re: Psml management > > > Good questions... strictly out-of the box > role-based-psml also wouldn't work for us for the same > reason, some users have more than one role. I have > some custom logic that only looks at the particular > roles which are associated with a "layout type"... in > the database these roles aren't differentiated from > other roles in any way. > > The question of users getting to chose their own role > doesn't apply to us; in fact users can't even directly > sign themselves up to jetspeed. Their jetspeed > account only gets created in response to an external > process which knows which role they are supposed to > be. > > -matt > > > --- Stefan Kuhn <[EMAIL PROTECTED]> wrote: > > Hi Metthew, > > I was thinking about giving psml to users depending > > on the role as well, but > > I came to the conclusion that this doesn't make > > sense because: When people > > subscribe (i. e. create a new account) they get one > > specified role anyway. Or > > do you leave to visitors to choose which role they > > want to have ? But then, > > when roles mean security restrictions, your securtiy > > is gone, because people > > can choose their role freely. So I thought it would > > be better to have the > > assignment of psmls if the administrator gives roles > > to users. > > One more problem: What to do if the user has got > > multiple roles - which psml > > take then ? Do you know what the built-in role-based > > psml does in such a case > > ? > > Thanks for your answers and sorry for asking > > questions instead of helping you. > > Stefan > > > > Am Mittwoch, 28. August 2002 23:55 schrieben Sie: > > > Here are my experiences with the jetspeed psml > > > management system. I've had to change a couple > > things > > > in ways which somebody else might find useful > > (please > > > let me know if so!) Also, I am discovering that I > > may > > > have a (hopefully reconcilable) philosophical > > problem > > > with PSML. > > > > > > Before I begin, our portal (still in development > > > stage) can be seen at > > > > > > http://nurse.ri.seawave.com:8180/portal/portal > > > > > > You can log in using "testcrew/password". > > > > > > > > > We don&#x
Re: Psml management
Good questions... strictly out-of the box role-based-psml also wouldn't work for us for the same reason, some users have more than one role. I have some custom logic that only looks at the particular roles which are associated with a "layout type"... in the database these roles aren't differentiated from other roles in any way. The question of users getting to chose their own role doesn't apply to us; in fact users can't even directly sign themselves up to jetspeed. Their jetspeed account only gets created in response to an external process which knows which role they are supposed to be. -matt --- Stefan Kuhn <[EMAIL PROTECTED]> wrote: > Hi Metthew, > I was thinking about giving psml to users depending > on the role as well, but > I came to the conclusion that this doesn't make > sense because: When people > subscribe (i. e. create a new account) they get one > specified role anyway. Or > do you leave to visitors to choose which role they > want to have ? But then, > when roles mean security restrictions, your securtiy > is gone, because people > can choose their role freely. So I thought it would > be better to have the > assignment of psmls if the administrator gives roles > to users. > One more problem: What to do if the user has got > multiple roles - which psml > take then ? Do you know what the built-in role-based > psml does in such a case > ? > Thanks for your answers and sorry for asking > questions instead of helping you. > Stefan > > Am Mittwoch, 28. August 2002 23:55 schrieben Sie: > > Here are my experiences with the jetspeed psml > > management system. I've had to change a couple > things > > in ways which somebody else might find useful > (please > > let me know if so!) Also, I am discovering that I > may > > have a (hopefully reconcilable) philosophical > problem > > with PSML. > > > > Before I begin, our portal (still in development > > stage) can be seen at > > > > http://nurse.ri.seawave.com:8180/portal/portal > > > > You can log in using "testcrew/password". > > > > > > We don't plan on letting our users customize their > > portal pages at all in terms of the layout, > presence > > or absence of certain portlets. However, we need > to > > give them ways to customize attributes of their > > existing portlets. > > > > We also need to service more than one TYPE of > user, > > each with a different pre-defined set of panes and > > portlets. > > > > Correct me if I'm wrong, but we can't use > role-based > > PSML because that would prevent the use of > individual > > settings any change to a portlet attribute > would > > then be seen by ALL other users in the same role. > > > > Also, there is no single user from whom psml files > for > > new users could be copied, because that wouldn't > allow > > for different layouts for different types of > users. > > > > So I changed JetspeedSecurity to point to my own > > UserManagement class, and overrode the > > addDefaultPSML() method to make a copy of the psml > > associated with the user's role rather than the > psml > > of another user (like turbine). > > > > Not a huge deal, but now I am arriving at what > seems > > to be a bigger problem: > > Although the psml file of a user will differ from > > those of his/her peers only in very narrowly > defined > > ways (only in the manipulation of attributes for > > portlets), each user still has a separate copy of > the > > file. > > > > This means that as we add new functionality to our > > portal, adding new portlets and presumably moving > the > > existing ones around somewhat, ONLY new users will > > benefit from these changes. > > > > Everytime we want to add a new portlet, we'll have > to > > write a script that will iterate through > everyone's > > psml and manipulate the xml in a certain way, > adding > > entries for the new portlet the exact type of > > thing that was supposed to be short-circuited by > the > > Customizer. Presumably this will have to be done > > when the server is shut down, because otherwise > the > > psml files of any currently-logged-in users will > be > > overwritten back to their old state when a they > log > > out. > > > > Aren't the notions of CONTENT and SETTINGS > separable? > > Shouldn't this information be stored in 2 > separate > > files? Did I miss some way that the current psml >
Re: Psml management
Hi Metthew, I was thinking about giving psml to users depending on the role as well, but I came to the conclusion that this doesn't make sense because: When people subscribe (i. e. create a new account) they get one specified role anyway. Or do you leave to visitors to choose which role they want to have ? But then, when roles mean security restrictions, your securtiy is gone, because people can choose their role freely. So I thought it would be better to have the assignment of psmls if the administrator gives roles to users. One more problem: What to do if the user has got multiple roles - which psml take then ? Do you know what the built-in role-based psml does in such a case ? Thanks for your answers and sorry for asking questions instead of helping you. Stefan Am Mittwoch, 28. August 2002 23:55 schrieben Sie: > Here are my experiences with the jetspeed psml > management system. I've had to change a couple things > in ways which somebody else might find useful (please > let me know if so!) Also, I am discovering that I may > have a (hopefully reconcilable) philosophical problem > with PSML. > > Before I begin, our portal (still in development > stage) can be seen at > > http://nurse.ri.seawave.com:8180/portal/portal > > You can log in using "testcrew/password". > > > We don't plan on letting our users customize their > portal pages at all in terms of the layout, presence > or absence of certain portlets. However, we need to > give them ways to customize attributes of their > existing portlets. > > We also need to service more than one TYPE of user, > each with a different pre-defined set of panes and > portlets. > > Correct me if I'm wrong, but we can't use role-based > PSML because that would prevent the use of individual > settings any change to a portlet attribute would > then be seen by ALL other users in the same role. > > Also, there is no single user from whom psml files for > new users could be copied, because that wouldn't allow > for different layouts for different types of users. > > So I changed JetspeedSecurity to point to my own > UserManagement class, and overrode the > addDefaultPSML() method to make a copy of the psml > associated with the user's role rather than the psml > of another user (like turbine). > > Not a huge deal, but now I am arriving at what seems > to be a bigger problem: > Although the psml file of a user will differ from > those of his/her peers only in very narrowly defined > ways (only in the manipulation of attributes for > portlets), each user still has a separate copy of the > file. > > This means that as we add new functionality to our > portal, adding new portlets and presumably moving the > existing ones around somewhat, ONLY new users will > benefit from these changes. > > Everytime we want to add a new portlet, we'll have to > write a script that will iterate through everyone's > psml and manipulate the xml in a certain way, adding > entries for the new portlet the exact type of > thing that was supposed to be short-circuited by the > Customizer. Presumably this will have to be done > when the server is shut down, because otherwise the > psml files of any currently-logged-in users will be > overwritten back to their old state when a they log > out. > > Aren't the notions of CONTENT and SETTINGS separable? > Shouldn't this information be stored in 2 separate > files? Did I miss some way that the current psml > system can allow for this? If not, how much work > would have to be done to allow for this? I would > certainly be willing to adopt such a project rather > than resorting to the "mass update script" strategy > mentioned above... > > - > Matthew Forsyth > Seawave.com > > __ > Do You Yahoo!? > Yahoo! Finance - Get real-time stock quotes > http://finance.yahoo.com -- Stefan Kuhn M. A. MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745 Jena, Germany Tel: +49(0)3641 571261 - Fax: +49(0)3641 571202 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Psml management
Here are my experiences with the jetspeed psml management system. I've had to change a couple things in ways which somebody else might find useful (please let me know if so!) Also, I am discovering that I may have a (hopefully reconcilable) philosophical problem with PSML. Before I begin, our portal (still in development stage) can be seen at http://nurse.ri.seawave.com:8180/portal/portal You can log in using "testcrew/password". We don't plan on letting our users customize their portal pages at all in terms of the layout, presence or absence of certain portlets. However, we need to give them ways to customize attributes of their existing portlets. We also need to service more than one TYPE of user, each with a different pre-defined set of panes and portlets. Correct me if I'm wrong, but we can't use role-based PSML because that would prevent the use of individual settings any change to a portlet attribute would then be seen by ALL other users in the same role. Also, there is no single user from whom psml files for new users could be copied, because that wouldn't allow for different layouts for different types of users. So I changed JetspeedSecurity to point to my own UserManagement class, and overrode the addDefaultPSML() method to make a copy of the psml associated with the user's role rather than the psml of another user (like turbine). Not a huge deal, but now I am arriving at what seems to be a bigger problem: Although the psml file of a user will differ from those of his/her peers only in very narrowly defined ways (only in the manipulation of attributes for portlets), each user still has a separate copy of the file. This means that as we add new functionality to our portal, adding new portlets and presumably moving the existing ones around somewhat, ONLY new users will benefit from these changes. Everytime we want to add a new portlet, we'll have to write a script that will iterate through everyone's psml and manipulate the xml in a certain way, adding entries for the new portlet the exact type of thing that was supposed to be short-circuited by the Customizer. Presumably this will have to be done when the server is shut down, because otherwise the psml files of any currently-logged-in users will be overwritten back to their old state when a they log out. Aren't the notions of CONTENT and SETTINGS separable? Shouldn't this information be stored in 2 separate files? Did I miss some way that the current psml system can allow for this? If not, how much work would have to be done to allow for this? I would certainly be willing to adopt such a project rather than resorting to the "mass update script" strategy mentioned above... - Matthew Forsyth Seawave.com __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
