Re: security groups are not seed reader type data.

2012-06-22 Thread Jacques Le Roux
BTW, do we really need create-admin-user-login since it underneath uses load-admin-user-login? If yes, then, in order to prevent any confusions, we should document in create-admin-user-login description that it uses underneath load-admin-user-login Jacques From: "Jacques Le Roux" From: "Ja

Re: security groups are not seed reader type data.

2012-06-21 Thread Hans Bakker
Implemented as discussed with revision: r1352431 | hansbak | 2012-06-21 14:21:49 +0700 (Thu, 21 Jun 2012) | 2 lines split up securitypermissions as seed data and securitygroups as demo data with a single exception: the creation of a super security group which has general access to the system a

Re: security groups are not seed reader type data.

2012-06-20 Thread Jacques Le Roux
From: "Jacopo Cappellato" If it makes things clearer we could also rename create-admin-userlogin into create-super-userlogin But this is actually minor... At least, a good target description would be welcome... Jacques Jacopo On Jun 20, 2012, at 8:28 AM, Jacopo Cappellato wrote: On

Re: security groups are not seed reader type data.

2012-06-19 Thread Jacopo Cappellato
If it makes things clearer we could also rename create-admin-userlogin into create-super-userlogin But this is actually minor... Jacopo On Jun 20, 2012, at 8:28 AM, Jacopo Cappellato wrote: > > On Jun 20, 2012, at 7:59 AM, Hans Bakker wrote: > >> The create-admin-userlogin should be assoc

Re: security groups are not seed reader type data.

2012-06-19 Thread Jacopo Cappellato
On Jun 20, 2012, at 7:59 AM, Hans Bakker wrote: > The create-admin-userlogin should be associated with the new 'SUPER" security > group. Yes, this is exactly what I was thinking. Jacopo

Re: security groups are not seed reader type data.

2012-06-19 Thread Hans Bakker
Sure but it should be : ant load-extseed create-admin-user-login which will also include the seed itself and also the background jobs (in seed-initial) are created. The create-admin-userlogin should be associated with the new 'SUPER" security group. Regards, Hans On 06/20/2012 12:26 PM, Ja

Re: security groups are not seed reader type data.

2012-06-19 Thread Jacopo Cappellato
Hans, thank you for the great summary; please see my comment below: On Jun 20, 2012, at 3:39 AM, Hans Bakker wrote: > another problem left: > - > ./ant seed ext-seed will not load the group security filesso all > components will not be accessible > > suggestions

Re: security groups are not seed reader type data.

2012-06-19 Thread Hans Bakker
Proposed so far: Security files: xSecurityPermissionSeedData.xml containing the SecurityPermission; loaded as 'seed' data. xSecurityGroupDemoData.xml containing the SecurityGroup and SecurityGroupPermission data; loaded as 'demo' SUPER security group: There is however also a need to h

Re: security groups are not seed reader type data.

2012-06-19 Thread Jacques Le Roux
Then why not adding the suffixes Seed and Demo: xSecurityPermissionData.xml containing the SecurityPermission; loaded as 'seed' data. xSecurityGroupData.xml containing the SecurityGroup and SecurityGroupPermission data; loaded as 'seed-initial' data would be xSecurityPermissionSe

Re: security groups are not seed reader type data.

2012-06-19 Thread Jacopo Cappellato
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 Ju

Re: security groups are not seed reader type data.

2012-06-19 Thread Jacopo Cappellato
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 perspect

Re: security groups are not seed reader type data.

2012-06-19 Thread Adrian Crum
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

Re: security groups are not seed reader type data.

2012-06-19 Thread Hans Bakker
This is fine with me although it does not follow the 'seedData' and 'demoData' naming Regards, Hans On 06/19/2012 01:50 PM, Jacopo Cappellato wrote: Thanks to both of you (Hans for the clear definition of the problem, requirements and proposed solution; Adrian for the additional suggestio

Re: security groups are not seed reader type data.

2012-06-18 Thread Jacopo Cappellato
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, >

Re: security groups are not seed reader type data.

2012-06-18 Thread Hans Bakker
Thank you Adrian for the reply, So, can we split the security files into 2 separate files? xSecuritySeedData.xml containing the SecurityPermission and is 'seed' data. xSecurityData.xml containing the SecurityGroup and SecurityGroupPermission data which is 'seed-initial' data This cha

Re: security groups are not seed reader type data.

2012-06-18 Thread Adrian Crum
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

Re: security groups are not seed reader type data.

2012-06-18 Thread Hans Bakker
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

Re: security groups are not seed reader type data.

2012-06-18 Thread Adrian Crum
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.

Re: security groups are not seed reader type data.

2012-06-18 Thread Hans Bakker
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:

Re: security groups are not seed reader type data.

2012-06-18 Thread Hans Bakker
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 cas

Re: security groups are not seed reader type data.

2012-06-18 Thread Adrian Crum
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.

security groups are not seed reader type data.

2012-06-18 Thread Hans Bakker
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, ther