-
1. Re: User Portlet Discussion
Sounds great to me
"lost password" is very relevant..
Just remember that the old portlet "is already out there"
Somebody are using it as it is today.
These people will not get happy one day suddenly to see changed features. (Even that the features are better!!!!)
So it might be a good idea to
1) keep the old one, and isolate it (own war?)
2) create two new portlets with the features you suggest.
At my current job we are discussing making new software by changing old software. As buying a new car. Only few would suggest to build it on top an old rusty car. It might often be better and give less problems to just write new code :-) -
2. Re: User Portlet Discussion
Emanuel is talking about adding features.
Why keeping the old one ? Please give some use cases. For the end-users it won't change anything but having more features.
The "old one" will still work, we can keep the code for it but not define it in portlet.xml (to avoid confusion).
The identity services won't change so people who added features on the existing portlet (and never contributed back by the way ;) ) will still be able to use it.
The new user portlet, will be a complete rewrite. -
3. Re: User Portlet Discussion
Hello,
********************
Ordering the view of users, or roles.
********************
today, the users are not sorted.
after modify a user, the list show in different order.
quite confusing.
so, usual database / table gui features : sorting on each columns. (easy now with jsf components).
********************
configurable list of user
********************
Ability to chose the columns that show in the list.
The column of the properties of the profile.
when managing quiet a lot of users, one or two profile properties are usefull to see in the list.
- ordering on that property to immidiatly select the user to work on, like adding roles etc....
- view at a glance all the users that are "like this or like that". (no need to enter the user profile screen to see this).
example : see in the list the date of last visit of the portal.
********************
Multi selection screens, with action on the selected list.
********************
example : selection of n users, then adding this role to them.
********************
Logged in users
********************
the feature of seeing "who is logged in now".
I have seen this feature is being developped, and at least feasible with some interceptors of the new API.
This is not part of User profile data, but this info in one column of the user list would be nice, for admin working on a user data.
And it would be a good example on "how to do this" for people that want to make there own feature of this kind.
********************
Packaging the user stuff appart
********************
if not yet done.
a separate packaging for the user/role gui admin
a separate packaging for the identity services (this is not gui, but this is important too).
use case : for customizing, suppress the jboss package, and deploy a new customized one. This is more clean and quick for prod, or even quick installation of a new server for dev (upgrade RC1, RC2, GA, X.X.1 GA...)
********************
RichFaces ?
********************
if RichFaces is ready when this is developped : would be great
and a great example for the one that want to see "how to".
hope that helps -
4. Re: User Portlet Discussion
"thomas.heute@jboss.com" wrote:
Why keeping the old one ? Please give some use cases. For the end-users it won't change anything but having more features.
The reason for this should only be to ensure that existing usage would not be changed.
I assume that split into two will cause existing systems to loose features as long as they do not deploy the new second one.
We need to care about such things. Existing users must be able to upgrade.
And best run without any change. thats all.
An example NOT to follow was the upgrade to 2.6.1.GA where the JSF changed. This did not make happy existing users. -
5. Re: User Portlet Discussion
"anders3" wrote:
An example NOT to follow was the upgrade to 2.6.1.GA where the JSF changed. This did not make happy existing users.
I find this quite offending since i already explained that to you.
Upgrading to 2.6.1.GA has nothing to do with JSF changed.
You had 2.6.0.GA running on JBoss AS 4.0.5 ? Fine, run 2.6.1.GA on JBoss AS 4.0.5, we made everything so that it can work on both.
Again, the bundle version is now including JBoss AS 4.2.1.GA (instead of JBoss AS 4.0.5), the bundle version is targeting people who want to get an easy start (not for a migration then).
There was no breaking change between 2.6.0.GA and 2.6.1.GA only bug fixes.
Now on the User portlet changes, i still don't understand your issues, can you please give me a clear use case.
If the portlet changes from JSP to JSF and is reorganized *internally* would that have an impact on your end-users ?
We'll keep the code of the former one, but what i don't want is to bring confusion by having 2 user portlets deployed out of the box. Only the new one will be deployed.
That said, we didn't talk yet about having the new portlet in 2.6 Branch or 2.8. -
6. Re: User Portlet Discussion
"thomas.heute@jboss.com" wrote:
I find this quite offending since i already explained that to you.
Upgrading to 2.6.1.GA has nothing to do with JSF changed. ...
My objectives are not to offend anybody, so sorry if that is the case.
My objectives are to ensure that uses can migrate to new versions of the portal as easy as possible.
I think my mission is complete in this discussion -
7. Re: User Portlet Discussion
"Antoine_h" wrote:
Hello,
********************
Ordering the view of users, or roles.
********************
Makes sense."Antoine_h" wrote:
********************
configurable list of user
********************
Makes sense even more since the list of attributes could be changed"Antoine_h" wrote:
********************
Multi selection screens, with action on the selected list.
********************
Makes sense as of today, but this would somehow duplicate the notion of group that will probably happen in the identity service"Antoine_h" wrote:
********************
Logged in users
********************
I was more seeing this as an additional portlet."Antoine_h" wrote:
********************
Packaging the user stuff appart
********************
a separate packaging for the user/role gui admin
The initial idea is to "move" this to the core-admin module (where the admin portlet leaves, after refactoring). I was thinking of a core-identity module instead, both solutions have advantages and drawbacks. But this will definitely move away the core module."Antoine_h" wrote:
a separate packaging for the identity services (this is not gui, but this is important too).
It is already the case in 2.6 (module called "identity")"Antoine_h" wrote:
********************
RichFaces ?
********************
I guess Emanuel will use anything he may need and is ready to use. But this is not a sample portlet so the goal is not to use a particular technology for the sake of using it.
Thanks a lot for the feedback and the new ideas to keep in mind.