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" <adrian.c...@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