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
