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

Reply via email to