Hi Trong,

One of the points of COR-313 is to force the update of users on startup with the content in the file. It might be useful for example in case when you have many portal containers (let's say 10) and you want to update user in all OrganizationServices in all portal containers and you want to be sure that the user 'john' represents same user in all those portal containers.

So my vote is for option1 "enable him, and save", which will ensure that user will be always enabled in all portal containers and all attributes of this user will be same like in the file.

I am also thinking about adding support for "disabled" attribute as well to OrganizationConfig.User class, which will add the possibility to disable the user at startup in all portal containers (Hence we avoid situation when portal administrator wants to disable 'john' in GateIn UI, but he disable him just for portal container 'portal' but john will be still enabled in 'sample-portal'). WDYT?

Marek

On 7.1.2014 08:16, Trong Tran wrote:
Hi Marek,

Regarding to "https://jira.exoplatform.org/browse/COR-313 Add "updateUsers" option to OrganizationDatabaseInitialize
r". There is an use case that user already exists BUT he is disabled status, we are wondering if it should force updating this user or not.

We have created https://jira.exoplatform.org/browse/COR-317 to address this issue and we also would like to know your opinion on this

Thanks



On 11 December 2013 16:34, Marek Posolda <mposolda@redhat.com> wrote:
On 11.12.2013 07:48, Hai Nguyen wrote:


---------- Forwarded message ----------
From: Hai Nguyen <haint@exoplatform.com>
Date: Wed, Dec 11, 2013 at 8:39 AM
Subject: Re: [gatein-dev] Setup Root password feature improvement
To: Marek Posolda <mposolda@redhat.com>





On Tue, Dec 10, 2013 at 6:08 PM, Marek Posolda <mposolda@redhat.com> wrote:
On 9.12.2013 11:35, Hai Nguyen wrote:
 
> - The SetupOrganizationDatabaseInitializer was clone of
> OrganizationDatabaseInitializer (in core service), that is hard for maintain

Yes, I agree that clone was not more elegant way, but there was not possibility to extend OrganizationDatabaseInitializer with a custom class, so clone was the only option to add custom behaviour.

I would suggest to give the ability to extend this class and override logic from other localization rather that exo.core module.

IMO, the new behaviors are not much to introduce a new custom class. Beside, I don't know why we need introduce more "updateUsers" property that is not necessary. If you looking for my PR, you will see we don't need SetupOrganizationDatabaseInitializer for this feature
Property "updateUsers" is another thing unrelated to Root user password setup. It's mentioned in this JIRA https://issues.jboss.org/browse/GTNPORTAL-3296 . It would be nice if OrganizationDatabaseInitializer from eXo core doesn't have all methods private, so we don't need to fork whole class into GateIn if some minor change is required. I can create JIRA to eXo core for this and also for "updateUsers" support. WDYT?


 +1 :)
Created:
https://jira.exoplatform.org/browse/COR-313 Add "updateUsers" option to OrganizationDatabaseInitializer
https://jira.exoplatform.org/browse/COR-314 Refactor OrganizationDatabaseInitializer to be better extensible

I would be happy to not remove SetupOrganizationDatabaseInitializer from GateIn master and 3.6.x until COR-313 will be available in exo.core and dependency updated in GateIn to version where it's available.

Thanks,
Marek 




_______________________________________________
gatein-dev mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev


_______________________________________________
gatein-dev mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev



--
Trong Tran
(+84) 983841909 | trongtt@gmail.com
Twitter: http://twitter.com/trongtt