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
