Hi Randy, Thanks for the tip.
Using the path profile does indeed work that way. User directories are still created, however, and as opposed to my approach of emptying the template directory, they have copies of the template dir files, although they don't appear to be used. I have not succeeded in reproducing the NPE. I was trying multiple various changes and strategies to try to achieve my results when I saw that, so I'm not exactly sure what caused it. If see it again, I will try to find the stack trace and send it to you. In general, I would be happy to work with the trunk and try to help you all make improvements. However, as we decided to make all these changes fairly late in our project, I'm feeling a bit of pressure to just "make it work." I will have a look at the trunk when I can, and if you have specific requests to test or provide feedback, let me know. Thanks, Linus > -----Message d'origine----- > De : Randy Watler [mailto:[email protected]] > Envoyé : Tuesday, March 02, 2010 7:02 PM > À : Jetspeed Users List > Objet : Re: self-registration portlet, user trees, and subsites > > Linus, > > You can achieve most of what you are asking for with a simple profiling > rule in place of the default 'j2' rule for registration. Try the 'path' > profiling rule. There might be a bug in the system that is preventing > the registration from working w/o a template directory. File a JIRA > issue if that is the case with a stack trace of the NPE. > > There are discussions going on right now having to do with the > simplifying this kind of configuration for 2.2.1. If you are willing to > work with the trunk, we can probably help you get it working as you'd like. > > Randy > > Linus Kamb wrote: > > Ok, well I think I've figured out a way to achieve at least part of what > > I'm trying to do. > > > > If I simply empty the _user/template directory, I realize the portal > > behavior that I want, that > is, all users see the same view, as controlled by the admin and constraints. > > > > Each user still has a directory created under _user, which I'd prefer to > > avoid if possible, but I > can live with that if it is not possible or convenient to prevent. > > > > cheers, > > Linus > > > > > > > >> -----Message d'origine----- > >> De : Linus Kamb [mailto:[email protected]] > >> Envoyé : Tuesday, March 02, 2010 11:08 AM > >> À : 'Jetspeed Users List' > >> Objet : self-registration portlet, user trees, and subsites > >> > >> Hi, > >> > >> > >> > >> I apologize for a bunch of newbie questions here, but I've taken over a > >> portal site and we're > >> trying to upgrade from 2.1.3 to 2.2.0, and rebuilding the site from > >> scratch, so a lot of stuff > that > >> was put in place before I got here (by someone no longer here) needs to be > >> put back, and I'm at > a > >> bit of a loss for some of the items. > >> > >> > >> > >> In our current 2.1.3 site, self-registration was apparently "broken" so > >> they have had to add all > >> the users by hand. This is not acceptable going forward, but it had the > >> consequence of all > users > >> seeing a single view of the portal site (which is what we want.) That > >> is, if the admin changes > >> the content of the site or of a particular page, that is reflected for > >> everyone. In addition, > >> there is not a directory tree created for every user. We don't need or > >> want individual users > >> changing things, and don't need subsites. When new users are created they > >> all see basically > what > >> the admin has laid out. (Admin vs user views and a couple of guest vs > >> user views are controlled > >> through constraints, which I think I understand.) > >> > >> > >> > >> Perhaps this is not the way it's supposed to be, but it has been working > >> for us. > >> > >> > >> > >> Now, upgrading to 2.2.0, I would like to make the self-registration > >> portlet work in more-or-less > >> the same manner. I've been poking at it in various ways, including > >> editing the new user > defaults > >> in the security admin pages, as well as the self-registration defaults, > >> but all I've managed to > do > >> is either not affect anything (eg, new folder for each user, new user > >> pages are from the > >> user/template tree,) or else break it with various errors including NPE > >> and "destination already > >> exists." > >> > >> > >> > >> So, in summary, what I would like is for the admin to be able to make > >> changes in one place > (using > >> the portal page-editing tools), and have all users, including > >> self-registered new users, see > those > >> pages and changes. > >> > >> > >> > >> Is this reasonable? Doable? And if so, how do I go about affecting it? > >> > >> > >> > >> I admit I don't fully understand the profiling rules, so I don't know if > >> they come in to play > here. > >> > >> > >> > >> thanks a lot, > >> > >> Linus > >> > >> > >> > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
