You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Hans Bakker <ma...@antwebsystems.com> on 2012/06/18 10:42:50 UTC
security groups are not seed reader type data.
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
Re: security groups are not seed reader type data.
Posted by Hans Bakker <ma...@antwebsystems.com>.
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 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
Re: security groups are not seed reader type data.
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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
>
Re: security groups are not seed reader type data.
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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
Re: security groups are not seed reader type data.
Posted by Hans Bakker <ma...@antwebsystems.com>.
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 and which is used with the 'ant
create-admin-user-login' command.
Regards,
Hans
Re: security groups are not seed reader type data.
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <ja...@les7arts.com>
> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>> 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 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.
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> 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 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.
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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 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.
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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.
Posted by Hans Bakker <ma...@antwebsystems.com>.
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, Jacopo Cappellato wrote:
> 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 files....so all components will not be accessible
>>
>> suggestions for this problem?
> I actually didn't look at the details but if in a newly created instance we run this:
>
> ant load-seed create-admin-user-login
>
> this will load all seed data (including the "super" permission group) only and will also load a user login; I was thinking that the "admin user" we create using ant could be associated to the "super" permission group; wouldn't this be enough to log in?
>
> Regards,
>
> Jacopo
Re: security groups are not seed reader type data.
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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 files....so all components will not be accessible
>
> suggestions for this problem?
I actually didn't look at the details but if in a newly created instance we run this:
ant load-seed create-admin-user-login
this will load all seed data (including the "super" permission group) only and will also load a user login; I was thinking that the "admin user" we create using ant could be associated to the "super" permission group; wouldn't this be enough to log in?
Regards,
Jacopo
Re: security groups are not seed reader type data.
Posted by Hans Bakker <ma...@antwebsystems.com>.
Proposed so far:
Security files:
xxxxxSecurityPermissionSeedData.xml containing the SecurityPermission;
loaded as 'seed' data.
xxxxxSecurityGroupDemoData.xml containing the SecurityGroup and
SecurityGroupPermission data; loaded as 'demo'
SUPER security group:
There is however also a need to have a seed loaded sytem or super
security group which relates to all xxxx_ADMIN permissions in all
components and the SERVICE_INVOKE_ANY permission of the service component.
another problem left:
-----------------------------
./ant seed ext-seed will not load the group security files....so all
components will not be accessible
suggestions for this problem?
Regards,
Hans
On 06/19/2012 06:54 PM, Jacques Le Roux wrote:
> Then why not adding the suffixes Seed and Demo:
>
>>> xxxxxSecurityPermissionData.xml containing the SecurityPermission;
>>> loaded as 'seed' data.
>>> xxxxxSecurityGroupData.xml containing the SecurityGroup and
>>> SecurityGroupPermission data; loaded as 'seed-initial' data
>
> would be
> xxxxxSecurityPermissionSeedData.xml containing the SecurityPermission;
> loaded as 'seed' data.
> xxxxxSecurityGroupDemoData.xml containing the SecurityGroup and
> SecurityGroupPermission data; loaded as 'seed-initial' data
>
> Jacques
>
> From: "Adrian Crum" <ad...@sandglass-software.com>
>> 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
Re: security groups are not seed reader type data.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Then why not adding the suffixes Seed and Demo:
>> xxxxxSecurityPermissionData.xml containing the SecurityPermission; loaded as 'seed' data.
>> xxxxxSecurityGroupData.xml containing the SecurityGroup and SecurityGroupPermission data; loaded as 'seed-initial' data
would be
xxxxxSecurityPermissionSeedData.xml containing the SecurityPermission; loaded as 'seed' data.
xxxxxSecurityGroupDemoData.xml containing the SecurityGroup and SecurityGroupPermission data; loaded as 'seed-initial' data
Jacques
From: "Adrian Crum" <ad...@sandglass-software.com>
>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
Re: security groups are not seed reader type data.
Posted by Adrian Crum <ad...@sandglass-software.com>.
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
Re: security groups are not seed reader type data.
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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
>>>>>>
>>>>>
>>>
>
Re: security groups are not seed reader type data.
Posted by Hans Bakker <ma...@antwebsystems.com>.
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
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
>>>>>
>>>>
>>
Re: security groups are not seed reader type data.
Posted by Adrian Crum <ad...@sandglass-software.com>.
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
>>>>
>>>
>
Re: security groups are not seed reader type data.
Posted by Hans Bakker <ma...@antwebsystems.com>.
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
>>>
>>
Re: security groups are not seed reader type data.
Posted by Adrian Crum <ad...@sandglass-software.com>.
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
>>
>
Re: security groups are not seed reader type data.
Posted by Hans Bakker <ma...@antwebsystems.com>.
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
>
Re: security groups are not seed reader type data.
Posted by Hans Bakker <ma...@antwebsystems.com>.
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
Re: security groups are not seed reader type data.
Posted by Adrian Crum <ad...@sandglass-software.com>.
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