Hello Benedict.
1) The privilege names can be defined free in your .xsprivilege file. You can define any number of privileges you need. There is not restriction to special names. How the privilege names are used to steer the privileges is done using the .xsaccess file and roles.
2) By adding a specific privilege to an .xsaccess file, the privilege steers the access to the package to which the .xsaccess file belongs (also the sub-packages are affected if no specific .xsaccess file(s) are available for the sub-packages).
Example package structure:
- mypackage
- .xsprivilege (defines privileges "admin_tools", "dummy_tools")
- admin_tools (package)
- .xsaccess (with "mypackage::admin_tools" privilege)
- admin_tool_service.xsjs
- dummy_tools (package)
- .xsaccess (with "mypackage::dummy_tools" privilege)
- dummy_tool_service.xsjs
A user which has assigned the application privilege "mypackage::admin_tools" assigned via a role can execute the xsjs service in the admin_tools sub-package. A user which has assigned the application privilege "mypackage::dummy_tools" via a role can execute the xsjs service in the dummy_tools sub-package.
3) Via a role an application privilege has to be assigned to the users who needs it. Without giving users the application privilege the "secured" objects can not be executed. What exactly can be executed with a specific application privilege is steered by the "package assignment" due to the definition in the .xsaccess file. In an XSJS also the $.session.assertAppPrivilege method (JSDoc: Class: Session) can be used to check if a user has a specific application privilege assigned.
Regards,
Florian