Re: [gatein-dev] Adding new field displayName for User

The more I think about that the more I realize that it is simply not possible to apply it to JCR 1.14.x. Imagine one second what it means in case of the data is stored into a table, between JCR 1.14.6 and JCR 1.14.7 the structure of the table will change due to a new added field. We would need to deliver a migration tool to at least do the required "ALTER TABLE" to allow to migrate from 1.14.6 to 1.14.7, I don't believe that we can afford this kind of changes in 1.14.x anymore, so I'm sorry but I postpone it to the next JCR version. Please note that you can do it at IDM level if it is critical for you.

So you will add methods getDisplayName() and setDisplayName to User interface in the end right? And in which JCR release and when will it be available? So as you proposed in UI we can use getFullName and setFullName and then change to getDisplayName and setDisplayName after EXOJCR-1780 will be fixed and available in GateIn. And name of persistent field in database will be "displayName" from the beginning to assure backward compatibility with future versions. Thanks, Marek On 23.2.2012 13:56, Nicolas Filotto wrote: > OK so what I propose is to use this field as temporary place > holder in order to have this feature asap but in the next version > the methods getFullName() and setFullName will be deprecated and > will be replaced with getDisplayName and setDisplayName to have > indeed a more appropriate name. At JCR level we will implement > the storage part of the job knowing that the future name is > displayName, I believe that IDM Team should apply the same logic > > On Thu, Feb 23, 2012 at 12:46 PM, Marek Posolda > <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: > > On 23.2.2012 13:41, Nicolas FILOTTO wrote: >> In EXOJCR-1780 you don't expect to persist the value right? >> it is only a runtime value? > No, It should be persistent. Sorry if it's not clear from my > description of EXOJCR-1780. I've just edited it to be more clear. > > Point is that user will change his "Display Name" in UI > during his registration (or update) and it will be then shown > in right top corner anytime later when this user will login > into GateIn portal. > >> >> On Thu, Feb 23, 2012 at 12:37 PM, Marek Posolda >> <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: >> >> On 23.2.2012 12:00, Julien Viet wrote: >>> I agree it's a bit of a hack, but that sounds like the >>> best tradeoff we can afford at the moment. >>> >>> for EXOJCR I think you can reasonably add the JIRA. >> I've added https://issues.jboss.org/browse/EXOJCR-1780 >> >> >>> >>> for GateIn trunk, that will requires perhaps minor UI >>> modification to add the new field that is not computed >>> anymore. >>> >>> as for the 3.2 release, the work should be done in a >>> branch and merged later (or the work can start after >>> 3.2 release). >> I will do it after GateIn 3.2 release. In GateIn we can >> also fork class UserImpl into portal codebase (into >> artifact exo.portal.component.identity, which is defacto >> Picketlink IDM based implementation of Organization api >> used in GateIn by default) to have this feature before >> EXOJCR-1780 will be fixed and available in GateIn. >> >> Only thing is that with other eXo Organization API >> implementations, it won't not work correctly if these >> implementations don't have required support for editable >> fullName (so fullName will be editable in UI but won't >> be persisted if particular organization api >> implementation don't support persistence for it). Can I >> go this way or should I wait for EXOJCR-1780? >> >>> >>> On Feb 23, 2012, at 11:50 AM, Marek Posolda wrote: >>> >>>> Ok, it's possible to avoid changing in User interface >>>> and use fullName field for it. However I think that >>>> it's not so clear from semantics perspective as >>>> fullName always means combination of firstName >>>> lastName when displayName, which will be editable by >>>> user, can be something completely different (like >>>> email address). But looks like we don't have much >>>> other choices if we want to avoid change of User >>>> interface... >>>> >>>> However in GateIn UI, I would be for using label >>>> "Display Name" for this new field. Is it ok? And it >>>> would mean that class >>>> org.exoplatform.services.organization.impl.UserImpl >>>> will need to add new field: private String lastName = >>>> null; >>>> >>>> with implementations like: >>>> >>>> public String getFullName() >>>> { >>>> return this.fullName != null ? this.fullName : >>>> getFirstName() + " " + getLastName(); >>>> } >>>> >>>> public void setFullName(String fullName) >>>> { >>>> this.fullName = fullName; >>>> } >>>> >>>> Do you want me to create JIRA in EXOJCR for it? >>>> >>>> I think that for GateIn 3.2 is late anyway because >>>> AFAIK release will be in next few days. >>>> >>>> Thanks, >>>> Marek >>>> >>>> On 23.2.2012 10:54, Nicolas FILOTTO wrote: >>>>> Indeed you are right this field exists and should be >>>>> used for this purpose. This way we have nothing to >>>>> change in top level applications (apart the ability >>>>> to modify it of course), we only need to implement >>>>> these methods to store/retrieve it properly in/from >>>>> the data store in the different implementation of the >>>>> OrganizationService which is more acceptable/doable >>>>> for GateIn 3.2/ JCR 1.14 if it is really needed to >>>>> have it asap >>>>> >>>>> On Thu, Feb 23, 2012 at 8:52 AM, Julien Viet >>>>> <julien(a)julienviet.com >>>>> <mailto:julien@julienviet.com>> wrote: >>>>> >>>>> The computed property "fullName" is persistable >>>>> and could be used for this display name. >>>>> >>>>> When the value does not exist: use the current >>>>> behavior "firstName lastName". >>>>> When a user saves a new value, it will be used >>>>> instead of the default computed value. >>>>> >>>>> There is already the setFullName(String) method >>>>> on the User interface that is empty in all >>>>> implementations. >>>>> >>>>> >>>>> On Feb 23, 2012, at 9:08 AM, Nicolas FILOTTO wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> How many customers are we talking about? I'm not >>>>>> against doing that for next versions but it is >>>>>> clearly too late for GateIn 3.2/JCR 1.14, it is >>>>>> not acceptable to modify interfaces in branches >>>>>> that are very close to be in maintenance mode. >>>>>> Moreover we would have 3 implementations of the >>>>>> Organization Service to review in very limited >>>>>> time only on eXo side, on your side you have IDM >>>>>> too. >>>>>> >>>>>> BR, >>>>>> Nicolas >>>>>> >>>>>> On Wed, Feb 22, 2012 at 9:49 PM, Marek Posolda >>>>>> <mposolda(a)redhat.com >>>>>> <mailto:mposolda@redhat.com>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> We have customers who would like to have >>>>>> editable "displayName" of user. >>>>>> Currently what's displayed in right top >>>>>> corner after login of user is >>>>>> his fullName, which is hardcoded as >>>>>> 'firstName lastName' . So we have >>>>>> suggestions to add new non-mandatory field >>>>>> displayName, which can be >>>>>> something similar like in Thunderbird >>>>>> https://wiki.mozilla.org/Thunderbird:Help_Documentation:Using_the_Address... >>>>>> . So user can fill displayName during his >>>>>> registration and it will be >>>>>> displayed in right top corner in >>>>>> UIUserInfoPortlet. If user won't have >>>>>> displayName, it will fallback to old >>>>>> behaviour and it will show fullName >>>>>> instead of it. >>>>>> >>>>>> What do you think about it? I already >>>>>> created JIRA >>>>>> https://issues.jboss.org/browse/GTNPORTAL-2358 >>>>>> with attached patches. >>>>>> First patch is for required changes in >>>>>> exo.core.component.organization.api . It's >>>>>> about adding 2 new methods >>>>>> "getDisplayName" and "setDisplayName" to >>>>>> interface User and change >>>>>> UserImpl implementation and other things >>>>>> according to it. Should I >>>>>> create JIRA into EXOJCR project for it? >>>>>> Second patch is for GateIn where needed >>>>>> changes are: >>>>>> - Adding new field into all portlets for >>>>>> creating and updating of user >>>>>> - Changing logic in UIUserInfoPortlet to use >>>>>> displayName with fallback >>>>>> to fullName >>>>>> >>>>>> Any objections? >>>>>> >>>>>> Thanks, >>>>>> Marek >>>>>> _______________________________________________ >>>>>> gatein-dev mailing list >>>>>> gatein-dev(a)lists.jboss.org >>>>>> <mailto:gatein-dev@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> gatein-dev mailing list >>>>>> gatein-dev(a)lists.jboss.org >>>>>> <mailto:gatein-dev@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>> >>>>> >>>> >>> >> >> > >