It is fine for me but if we treat them as demo data, we will need (as Hans suggested in another thread) a "system" group for the "system" userlogin wit super permissions as seed data.
Jacopo On Jun 19, 2012, at 10:59 AM, Adrian Crum wrote: > I prefer those names too. > > Btw, from my perspective, the security groups and their permission > assignments should be demo data. The only security data the applications > really need are the permissions. Security groups are there for demonstration > purposes, and most organizations will create their own. Maybe we can discuss > that in another thread. > > -Adrian > > On 6/19/2012 7:50 AM, Jacopo Cappellato wrote: >> Thanks to both of you (Hans for the clear definition of the problem, >> requirements and proposed solution; Adrian for the additional suggestions); >> I like the general idea but please see one minor comment inline: >> >> On Jun 19, 2012, at 8:00 AM, Hans Bakker wrote: >> >>> Thank you Adrian for the reply, >>> >>> So, can we split the security files into 2 separate files? >>> >>> xxxxxSecuritySeedData.xml containing the SecurityPermission and is 'seed' >>> data. >>> xxxxxSecurityData.xml containing the SecurityGroup and >>> SecurityGroupPermission data which is 'seed-initial' data >> Can we use the following naming conventions instead: >> >> xxxxxSecurityPermissionData.xml containing the SecurityPermission; loaded as >> 'seed' data. >> xxxxxSecurityGroupData.xml containing the SecurityGroup and >> SecurityGroupPermission data; loaded as 'seed-initial' data >> >> ? >> >> Kind regards, >> >> Jacopo >> >>> This change should not have any impact on the current functioning of the >>> system except for the fact that security seed data will not overwrite >>> group/permission assignments which are set by the menus after installation. >>> >>> any comments? >>> >>> Regards, >>> Hans >>> >>> >>> On 06/18/2012 05:50 PM, Adrian Crum wrote: >>>> Then maybe the security group definitions and their permission assignments >>>> should be moved to the seed-initial reader. >>>> >>>> -Adrian >>>> >>>> On 6/18/2012 11:23 AM, Hans Bakker wrote: >>>>> Adrian, i tried this way, i gave up on that, lets keep it simple? >>>>> >>>>> i just want this use case problem solved: >>>>> >>>>> as an ofbiz end user i want to be able to change the >>>>> securitygroup/permission assignment without it are being modified by >>>>> loading seed data. >>>>> >>>>> Can you suggest a solution? >>>>> >>>>> Regards, >>>>> Hans >>>>> >>>>> >>>>> On 06/18/2012 04:54 PM, Adrian Crum wrote: >>>>>> I believe this is a problem with multi-tenant installations, correct? >>>>>> Could you go into more detail about the process? It appears to me the >>>>>> process is something like this: >>>>>> >>>>>> 1. Deploy OFBiz in multi-tenant mode. >>>>>> 2. Start adding tenants, configure permissions for each tenant. >>>>>> 3. Install seed data. Seed data overwrites existing permission >>>>>> assignments - undoing the per-tenant permission settings. >>>>>> >>>>>> Is that correct? >>>>>> >>>>>> -Adrian >>>>>> >>>>>> On 6/18/2012 10:11 AM, Hans Bakker wrote: >>>>>>> perhaps confusing again, another try: >>>>>>> >>>>>>> as an ofbiz end user i want to be able to change the >>>>>>> securitygroup/permission assignment without it are being modified by >>>>>>> loading seed data. >>>>>>> >>>>>>> let me know what now is not clear.... >>>>>>> >>>>>>> regards, >>>>>>> Hans >>>>>>> >>>>>>> On 06/18/2012 04:03 PM, Hans Bakker wrote: >>>>>>>> Ok the use case: >>>>>>>> >>>>>>>> as a system end user i want to be able to change the >>>>>>>> securitygroup/permission assignment without they are being reset by >>>>>>>> loading seed data. >>>>>>>> >>>>>>>> would this help? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Hans >>>>>>>> >>>>>>>> On 06/18/2012 04:00 PM, Adrian Crum wrote: >>>>>>>>> Hans, >>>>>>>>> >>>>>>>>> It would help if we had a description of the use case - so that we >>>>>>>>> can decide if the solution you are proposing is appropriate. I know >>>>>>>>> you described the use case before, but could you try again with more >>>>>>>>> detail? I had a difficult time understanding the problem you are >>>>>>>>> trying to solve. >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> On 6/18/2012 9:42 AM, Hans Bakker wrote: >>>>>>>>>> Ok lets have another attempt om changing the security xml data >>>>>>>>>> perhaps in some smaller steps. >>>>>>>>>> >>>>>>>>>> All components have xxxSecurityData.xml 'seed' files. Theses files >>>>>>>>>> contain security groups, security permissions and relations between >>>>>>>>>> these two entities. Security permissions are real seed data, there >>>>>>>>>> are related to hardcoded business functions inside the programs. >>>>>>>>>> >>>>>>>>>> Security groups and the relation to permissions however are not seed >>>>>>>>>> data because they could be changed in production by the menus and >>>>>>>>>> then they are overwritten by the load-seed action. >>>>>>>>>> Isn't it so that Load-seed should always be possible without >>>>>>>>>> destroying setting by users, so not overwrite the permission group >>>>>>>>>> allocation? >>>>>>>>>> >>>>>>>>>> Suggestion to solve: >>>>>>>>>> Moving the security groups and the relations to permissions in >>>>>>>>>> separate files and give them a different reader type (security?) >>>>>>>>>> >>>>>>>>>> Problems: >>>>>>>>>> 1. when only seed is loaded all components are not accessible >>>>>>>>>> because the security groups are missing. >>>>>>>>>> 2. background jobs fail because security group FULLADMIN does not >>>>>>>>>> exist. >>>>>>>>>> >>>>>>>>>> These 2 problems can be solved by creation of a 'system' security >>>>>>>>>> group related with a system userid with the same access as FULLADMIN >>>>>>>>>> but which is loaded as seed data. >>>>>>>>>> >>>>>>>>>> Is this an acceptable solution? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Hans
