it is scoped for EPP 5.2.1 ? On Feb 22, 2012, at 10:49 PM, Marek Posolda 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 > https://lists.jboss.org/mailman/listinfo/gatein-dev

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&gt; 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 https://lists.jboss.org/mailman/listinfo/gatein-dev _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

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

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.

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).

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 >> >> >

In EXOJCR-1780 you don't expect to persist the value right? it is only a runtime value?

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 >>> >>> >> >

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 >>>> >>>> >>> >> > >

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 >>>>> >>>>> >>>> >>> >> >> > >

On Thu, Feb 23, 2012 at 1:36 PM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: On 23.2.2012 14:21, Nicolas Filotto wrote: > > 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. IDM implementation has attributes stored in separate table, so it's not needed to do any ALTER TABLE and it's not a problem to migrate from older versions. As I said I will use name of persistent attribute "displayName" to have backward compatibility with future versions with new major JCR. But then again, can we do changes in GateIn UI for it? As then it won't work in GateIn if you will switch from PicketlinkIDMORganizationServiceImpl to your OrganizationService implementations. Because if you can't add new persistent field in your organization service implementation, then the "Display Name" can't work correctly with them as it won't be persistent even if in UI it may seems that it is persistent and it will be confusing for users. We will tell our customers that it is simply not supported in this version On Thu, Feb 23, 2012 at 1:10 PM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > 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&gt; 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&gt; 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&gt; 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&gt; 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 >>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> gatein-dev mailing list >>>>>>> gatein-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>> >>>>>> >>>>> >>>> >>> >>> >> >> > > _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

can you clarify what you want to do (where do you want to add the displayName) ? it's not clear for me. On Feb 23, 2012, at 5:03 PM, Boleslaw Dawidowicz wrote: > Sorry for catching up late but was partly cut off from internet for most of the day. > > It seems that whatever scenario we choose (forking UserImpl or using fullName) you won't be able to support it in the UI for now anyway. We'll go with adding displayName then and get aligned when possible. > > I'm sorry - this requirement came quite late but it is rather important as use case is localization issues that you cannot solve in different way really. Thanks for being understanding on it. > > Bolek > > On Feb 23, 2012, at 3:15 PM, Nicolas Filotto wrote: > >> On Thu, Feb 23, 2012 at 1:36 PM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: >> On 23.2.2012 14:21, Nicolas Filotto wrote: >>> >>> 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. >> IDM implementation has attributes stored in separate table, so it's not needed to do any ALTER TABLE and it's not a problem to migrate from older versions. As I said I will use name of persistent attribute "displayName" to have backward compatibility with future versions with new major JCR. >> >> But then again, can we do changes in GateIn UI for it? As then it won't work in GateIn if you will switch from PicketlinkIDMORganizationServiceImpl to your OrganizationService implementations. Because if you can't add new persistent field in your organization service implementation, then the "Display Name" can't work correctly with them as it won't be persistent even if in UI it may seems that it is persistent and it will be confusing for users. >> We will tell our customers that it is simply not supported in this version >> >> >> On Thu, Feb 23, 2012 at 1:10 PM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: >>> 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&gt; 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&gt; 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&gt; 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&gt; 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 >>>>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> gatein-dev mailing list >>>>>>>>> gatein-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> _______________________________________________ >> gatein-dev mailing list >> gatein-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/gatein-dev > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev

to the User interface defined in EXOJCR ? On Feb 23, 2012, at 5:15 PM, Boleslaw Dawidowicz wrote: > Still discussing with Marek but in the end adding displayName seems like the best approach. > > Problem is that even if we reuse fullName we need to fork UserImpl anyway… Also even if we keep interface compatibility for now it will mean that persisting of this property won't work in UI with switched IDM implementation. My understanding is that currently for eXo changing interface is similar effort to changing tables - and won't happen until next major release. Am I right? > > Still if it matters for you to go with using "fullName" for now we can align - keep in mind that we still need to fork and change impl anyway and it won't change much your situation. > > Bolek > > On Feb 23, 2012, at 5:07 PM, Julien Viet wrote: > >> can you clarify what you want to do (where do you want to add the displayName) ? >> >> it's not clear for me. >> >> On Feb 23, 2012, at 5:03 PM, Boleslaw Dawidowicz wrote: >> >>> Sorry for catching up late but was partly cut off from internet for most of the day. >>> >>> It seems that whatever scenario we choose (forking UserImpl or using fullName) you won't be able to support it in the UI for now anyway. We'll go with adding displayName then and get aligned when possible. >>> >>> I'm sorry - this requirement came quite late but it is rather important as use case is localization issues that you cannot solve in different way really. Thanks for being understanding on it. >>> >>> Bolek >>> >>> On Feb 23, 2012, at 3:15 PM, Nicolas Filotto wrote: >>> >>>> On Thu, Feb 23, 2012 at 1:36 PM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: >>>> On 23.2.2012 14:21, Nicolas Filotto wrote: >>>>> >>>>> 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. >>>> IDM implementation has attributes stored in separate table, so it's not needed to do any ALTER TABLE and it's not a problem to migrate from older versions. As I said I will use name of persistent attribute "displayName" to have backward compatibility with future versions with new major JCR. >>>> >>>> But then again, can we do changes in GateIn UI for it? As then it won't work in GateIn if you will switch from PicketlinkIDMORganizationServiceImpl to your OrganizationService implementations. Because if you can't add new persistent field in your organization service implementation, then the "Display Name" can't work correctly with them as it won't be persistent even if in UI it may seems that it is persistent and it will be confusing for users. >>>> We will tell our customers that it is simply not supported in this version >>>> >>>> >>>> On Thu, Feb 23, 2012 at 1:10 PM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: >>>>> 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&gt; 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&gt; 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&gt; 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&gt; 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 >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> gatein-dev mailing list >>>>>>>>>>> gatein-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> gatein-dev mailing list >>>> gatein-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>> >>> _______________________________________________ >>> gatein-dev mailing list >>> gatein-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/gatein-dev >> >

what worries me (not much of course) is that we need to do this "temporarily" in the gatein code base until it is resolved properly later because it has to go in EPP product and it shall go in project first (where at the end nobody cares really) for some well established principle. On Feb 23, 2012, at 5:19 PM, Boleslaw Dawidowicz wrote: > To forked UserImpl only for now. To User interface whenever eXo is comfortable with. Or we stick to fullName if it matters for you. However in situation like this we deprecate and switch method later. Basically every choice is a mess here and has drawbacks. > > On Feb 23, 2012, at 5:16 PM, Julien Viet wrote: > >> to the User interface defined in EXOJCR ? >> >> On Feb 23, 2012, at 5:15 PM, Boleslaw Dawidowicz wrote: >> >>> Still discussing with Marek but in the end adding displayName seems like the best approach. >>> >>> Problem is that even if we reuse fullName we need to fork UserImpl anyway… Also even if we keep interface compatibility for now it will mean that persisting of this property won't work in UI with switched IDM implementation. My understanding is that currently for eXo changing interface is similar effort to changing tables - and won't happen until next major release. Am I right? >>> >>> Still if it matters for you to go with using "fullName" for now we can align - keep in mind that we still need to fork and change impl anyway and it won't change much your situation. >>> >>> Bolek >>> >>> On Feb 23, 2012, at 5:07 PM, Julien Viet wrote: >>> >>>> can you clarify what you want to do (where do you want to add the displayName) ? >>>> >>>> it's not clear for me. >>>> >>>> On Feb 23, 2012, at 5:03 PM, Boleslaw Dawidowicz wrote: >>>> >>>>> Sorry for catching up late but was partly cut off from internet for most of the day. >>>>> >>>>> It seems that whatever scenario we choose (forking UserImpl or using fullName) you won't be able to support it in the UI for now anyway. We'll go with adding displayName then and get aligned when possible. >>>>> >>>>> I'm sorry - this requirement came quite late but it is rather important as use case is localization issues that you cannot solve in different way really. Thanks for being understanding on it. >>>>> >>>>> Bolek >>>>> >>>>> On Feb 23, 2012, at 3:15 PM, Nicolas Filotto wrote: >>>>> >>>>>> On Thu, Feb 23, 2012 at 1:36 PM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: >>>>>> On 23.2.2012 14:21, Nicolas Filotto wrote: >>>>>>> >>>>>>> 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. >>>>>> IDM implementation has attributes stored in separate table, so it's not needed to do any ALTER TABLE and it's not a problem to migrate from older versions. As I said I will use name of persistent attribute "displayName" to have backward compatibility with future versions with new major JCR. >>>>>> >>>>>> But then again, can we do changes in GateIn UI for it? As then it won't work in GateIn if you will switch from PicketlinkIDMORganizationServiceImpl to your OrganizationService implementations. Because if you can't add new persistent field in your organization service implementation, then the "Display Name" can't work correctly with them as it won't be persistent even if in UI it may seems that it is persistent and it will be confusing for users. >>>>>> We will tell our customers that it is simply not supported in this version >>>>>> >>>>>> >>>>>> On Thu, Feb 23, 2012 at 1:10 PM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: >>>>>>> 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&gt; 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&gt; 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&gt; 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&gt; 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 >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> gatein-dev mailing list >>>>>>>>>>>>> gatein-dev(a)lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> gatein-dev mailing list >>>>>> gatein-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>> >>>>> _______________________________________________ >>>>> gatein-dev mailing list >>>>> gatein-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>> >>> >> >

However I think that requirement is not that no one cares - looks like they care a lot in Japan :-P Problem here is also execution and how we have dependencies split between GateIn and JCR. I'm not sure how we should address it in the future however now we are discussing something that is not really JCR related (talking semantics here) but is tightly connected to JCR release cycle. So thats the part that makes it complex also. Maybe it is a good point to start discussion if it is possible to decouple. We discussed previously about doing separate Authentication module and extracting things from SSO, WCI and core there. Nicolas - how tightly are core organization interfaces connected with JCR internals actually?

Would it be possible to extract part of those from core in the future? I'm talking really long term here - even scope of doing new public organization API.

Bolek On Feb 23, 2012, at 5:34 PM, Boleslaw Dawidowicz wrote: We can do it EPP only I guess. However my fear is that long term it can cause even grater mess with more out of sync :) Like I said if you prefer to go with fullName for now we can do it. Bolek On Feb 23, 2012, at 5:21 PM, Julien Viet wrote: what worries me (not much of course) is that we need to do this "temporarily" in the gatein code base until it is resolved properly later because it has to go in EPP product and it shall go in project first (where at the end nobody cares really) for some well established principle. On Feb 23, 2012, at 5:19 PM, Boleslaw Dawidowicz wrote: To forked UserImpl only for now. To User interface whenever eXo is comfortable with. Or we stick to fullName if it matters for you. However in situation like this we deprecate and switch method later. Basically every choice is a mess here and has drawbacks. On Feb 23, 2012, at 5:16 PM, Julien Viet wrote: to the User interface defined in EXOJCR ? On Feb 23, 2012, at 5:15 PM, Boleslaw Dawidowicz wrote: Still discussing with Marek but in the end adding displayName seems like the best approach. Problem is that even if we reuse fullName we need to fork UserImpl anyway… Also even if we keep interface compatibility for now it will mean that persisting of this property won't work in UI with switched IDM implementation. My understanding is that currently for eXo changing interface is similar effort to changing tables - and won't happen until next major release. Am I right? Still if it matters for you to go with using "fullName" for now we can align - keep in mind that we still need to fork and change impl anyway and it won't change much your situation. Bolek On Feb 23, 2012, at 5:07 PM, Julien Viet wrote: can you clarify what you want to do (where do you want to add the displayName) ? it's not clear for me. On Feb 23, 2012, at 5:03 PM, Boleslaw Dawidowicz wrote: Sorry for catching up late but was partly cut off from internet for most of the day. It seems that whatever scenario we choose (forking UserImpl or using fullName) you won't be able to support it in the UI for now anyway. We'll go with adding displayName then and get aligned when possible. I'm sorry - this requirement came quite late but it is rather important as use case is localization issues that you cannot solve in different way really. Thanks for being understanding on it. Bolek On Feb 23, 2012, at 3:15 PM, Nicolas Filotto wrote: On Thu, Feb 23, 2012 at 1:36 PM, Marek Posolda <mposolda(a)redhat.com&gt;wrote: > ** > On 23.2.2012 14:21, Nicolas Filotto wrote: > > 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. > > IDM implementation has attributes stored in separate table, so it's not > needed to do any ALTER TABLE and it's not a problem to migrate from older > versions. As I said I will use name of persistent attribute "displayName" > to have backward compatibility with future versions with new major JCR. > > But then again, can we do changes in GateIn UI for it? As then it won't > work in GateIn if you will switch from PicketlinkIDMORganizationServiceImpl > to your OrganizationService implementations. Because if you can't add new > persistent field in your organization service implementation, then the > "Display Name" can't work correctly with them as it won't be persistent > even if in UI it may seems that it is persistent and it will be confusing > for users. > We will tell our customers that it is simply not supported in this version > > > On Thu, Feb 23, 2012 at 1:10 PM, Marek Posolda <mposolda(a)redhat.com&gt;wrote: > > 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&gt;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&gt;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&gt;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&gt;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 >>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>> >>>>> >>>>> _______________________________________________ >>>>> gatein-dev mailing list >>>>> gatein-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >> >> > > _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

what worries me (not much of course) is that we need to do this "temporarily" in the gatein code base until it is resolved properly later because it has to go in EPP product and it shall go in project first (where at the end nobody cares really) for some well established principle. On Feb 23, 2012, at 5:19 PM, Boleslaw Dawidowicz wrote: > To forked UserImpl only for now. To User interface whenever eXo is > comfortable with. Or we stick to fullName if it matters for you. > However in situation like this we deprecate and switch method later. > Basically every choice is a mess here and has drawbacks. > > On Feb 23, 2012, at 5:16 PM, Julien Viet wrote: > >> to the User interface defined in EXOJCR ? >> >> On Feb 23, 2012, at 5:15 PM, Boleslaw Dawidowicz wrote: >> >>> Still discussing with Marek but in the end adding displayName seems >>> like the best approach. >>> >>> Problem is that even if we reuse fullName we need to fork UserImpl >>> anyway… Also even if we keep interface compatibility for now it >>> will mean that persisting of this property won't work in UI with >>> switched IDM implementation. My understanding is that currently for >>> eXo changing interface is similar effort to changing tables - and >>> won't happen until next major release. Am I right? >>> >>> Still if it matters for you to go with using "fullName" for now we >>> can align - keep in mind that we still need to fork and change impl >>> anyway and it won't change much your situation. >>> >>> Bolek >>> >>> On Feb 23, 2012, at 5:07 PM, Julien Viet wrote: >>> >>>> can you clarify what you want to do (where do you want to add the >>>> displayName) ? >>>> >>>> it's not clear for me. >>>> >>>> On Feb 23, 2012, at 5:03 PM, Boleslaw Dawidowicz wrote: >>>> >>>>> Sorry for catching up late but was partly cut off from internet >>>>> for most of the day. >>>>> >>>>> It seems that whatever scenario we choose (forking UserImpl or >>>>> using fullName) you won't be able to support it in the UI for now >>>>> anyway. We'll go with adding displayName then and get aligned >>>>> when possible. >>>>> >>>>> I'm sorry - this requirement came quite late but it is rather >>>>> important as use case is localization issues that you cannot >>>>> solve in different way really. Thanks for being understanding on it. >>>>> >>>>> Bolek >>>>> >>>>> On Feb 23, 2012, at 3:15 PM, Nicolas Filotto wrote: >>>>> >>>>>> On Thu, Feb 23, 2012 at 1:36 PM, Marek Posolda >>>>>> <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: >>>>>> >>>>>> On 23.2.2012 14:21, Nicolas Filotto wrote: >>>>>>> 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. >>>>>> IDM implementation has attributes stored in separate table, >>>>>> so it's not needed to do any ALTER TABLE and it's not a >>>>>> problem to migrate from older versions. As I said I will use >>>>>> name of persistent attribute "displayName" to have backward >>>>>> compatibility with future versions with new major JCR. >>>>>> >>>>>> But then again, can we do changes in GateIn UI for it? As >>>>>> then it won't work in GateIn if you will switch from >>>>>> PicketlinkIDMORganizationServiceImpl to your >>>>>> OrganizationService implementations. Because if you can't >>>>>> add new persistent field in your organization service >>>>>> implementation, then the "Display Name" can't work correctly >>>>>> with them as it won't be persistent even if in UI it may >>>>>> seems that it is persistent and it will be confusing for users. >>>>>> >>>>>> We will tell our customers that it is simply not supported in >>>>>> this version >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Feb 23, 2012 at 1:10 PM, Marek Posolda >>>>>> <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: >>>>>>> >>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >> > _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

Hi, so implementation is done and I attached proposed patch GTNPORTAL-2358-fullName.patch to https://issues.jboss.org/browse/GTNPORTAL-2358 . What I did is: - Adding new UI field with name "displayName" to all UI forms, where you can create or edit user ( UIRegisterInputSet, UIAccountProfiles, UIAccountInputSet, UIAccountEditInputSet ). So name of UI field is "displayName" and name of localization label is also "displayName". I added localizations only for "en" and "cs" properties bundles as I don't know other languages :) - UI components are communicating with User interface via "setFullName" and "getFullName". So fullName is now used as temporary placeholder until methods "getDisplayName" and "setDisplayName" will be available in Organization API. I added "TODO: GTNPORTAL-2358" in all pieces of code, which needs to be changed once displayName will be available in Organization API. This will allow us to use getDisplayName and setDisplayName and get rid of fullName as temporary placeholder. - IDM integration is changed to support persistent implementations of "getFullName" and "setFullName". For this purpose I forked class UserImpl from Organization API (I made a subclass of eXo UserImpl class with overriden methods getFullName and setFullName). Again, name of new attribute at DB level is "displayName", which will assure compatibility with future versions (after support for displayName in Organization API will be added). Let me know if it looks ok. I also not sure what is final decision of having it in GateIn. I think we have possibilities: - push it to GateIn 3.2.GA (but I guess it's too late for it) - push it to GateIn trunk after 3.2.GA release (This is what i can propose) - don't add it to GateIn until displayName support in Organization api, because persistent displayName field can't work with eXo OrganizationService implementations. Thanks, Marek On 23.2.2012 17:21, Julien Viet wrote: > > what worries me (not much of course) is that we need to do this "temporarily" in the gatein code base until it is resolved properly later because it has to go in EPP product and it shall go in project first (where at the end nobody cares really) for some well established principle. > > > On Feb 23, 2012, at 5:19 PM, Boleslaw Dawidowicz wrote: > >> To forked UserImpl only for now. To User interface whenever eXo is comfortable with. Or we stick to fullName if it matters for you. However in situation like this we deprecate and switch method later. Basically every choice is a mess here and has drawbacks. >> >> On Feb 23, 2012, at 5:16 PM, Julien Viet wrote: >> >>> to the User interface defined in EXOJCR ? >>> >>> On Feb 23, 2012, at 5:15 PM, Boleslaw Dawidowicz wrote: >>> >>>> Still discussing with Marek but in the end adding displayName seems like the best approach. >>>> >>>> Problem is that even if we reuse fullName we need to fork UserImpl anyway… Also even if we keep interface compatibility for now it will mean that persisting of this property won't work in UI with switched IDM implementation. My understanding is that currently for eXo changing interface is similar effort to changing tables - and won't happen until next major release. Am I right? >>>> >>>> Still if it matters for you to go with using "fullName" for now we can align - keep in mind that we still need to fork and change impl anyway and it won't change much your situation. >>>> >>>> Bolek >>>> >>>> On Feb 23, 2012, at 5:07 PM, Julien Viet wrote: >>>> >>>>> can you clarify what you want to do (where do you want to add the displayName) ? >>>>> >>>>> it's not clear for me. >>>>> >>>>> On Feb 23, 2012, at 5:03 PM, Boleslaw Dawidowicz wrote: >>>>> >>>>>> Sorry for catching up late but was partly cut off from internet for most of the day. >>>>>> >>>>>> It seems that whatever scenario we choose (forking UserImpl or using fullName) you won't be able to support it in the UI for now anyway. We'll go with adding displayName then and get aligned when possible. >>>>>> >>>>>> I'm sorry - this requirement came quite late but it is rather important as use case is localization issues that you cannot solve in different way really. Thanks for being understanding on it. >>>>>> >>>>>> Bolek >>>>>> >>>>>> On Feb 23, 2012, at 3:15 PM, Nicolas Filotto wrote: >>>>>> >>>>>>> On Thu, Feb 23, 2012 at 1:36 PM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: >>>>>>> On 23.2.2012 14:21, Nicolas Filotto wrote: >>>>>>>> >>>>>>>> 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. >>>>>>> IDM implementation has attributes stored in separate table, so it's not needed to do any ALTER TABLE and it's not a problem to migrate from older versions. As I said I will use name of persistent attribute "displayName" to have backward compatibility with future versions with new major JCR. >>>>>>> >>>>>>> But then again, can we do changes in GateIn UI for it? As then it won't work in GateIn if you will switch from PicketlinkIDMORganizationServiceImpl to your OrganizationService implementations. Because if you can't add new persistent field in your organization service implementation, then the "Display Name" can't work correctly with them as it won't be persistent even if in UI it may seems that it is persistent and it will be confusing for users. >>>>>>> We will tell our customers that it is simply not supported in this version >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 23, 2012 at 1:10 PM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: >>>>>>>> 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&gt; 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&gt; 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&gt; 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&gt; 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 >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> gatein-dev mailing list >>>>>>>>>>>>>> gatein-dev(a)lists.jboss.org >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> gatein-dev mailing list >>>>>>> gatein-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>>> >>>>>> _______________________________________________ >>>>>> gatein-dev mailing list >>>>>> gatein-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/gatein-dev >>>>> >>>> >>> >> > > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev