instead of "system" we could name the group as "super" or similar and we could apply it also when we create (using the ant task) the admin user; in this way will have an easy way to let a user log in in a system with seed data only.
ant clean-all load-seed create-admin-user-login Jacopo On Jun 19, 2012, at 11:24 AM, Jacopo Cappellato wrote: > 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 >
