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