I have a number of Team definitions, defined via Project properties->Teams.
If I look at the Role business object via a Table on a page, I see additional roles that aren’t defined in Teams. The ones in the table have different create dates.
An example is:
NewsAdministrator - defined in Project Properties and in the Roles Table
News Administrators - defined only in the Roles table
Role is a business object that creates a corresponding table in the database.
When you add a team in project + settings + teams, generate creates a create-static-roles.observer.ts file containing logic that runs on app start to be sure that there is a role row for each team.
If you have a team and then later delete it, the role row will still be in the database. You can simply remove the extra entries using API Explorer.
As a side point, you can also have role rows that are created dynamically at runtime. Those cannot be referenced in the access settings at design time (only static roles (teams) can be referenced) but they can be referenced by server side business logic that checks which roles a user is assigned.
ok, that explains the extra entries, old teams that I had deleted (but are still in the database as you say). Seems like a bit of a security hole to me, if user connections to that role could possible be exploited, though a small risk.
Two questions:
- On the dynamic roles, created through server side business logic, these can just be done by creating an instance in the Role business object, then App-to-Role, right?
- But any dynamic role must be used in scripting, correct?
Yes. You can create dynamic roles by doing Role.create on the client side or the server side. One simple example we have had in the past is to create a dynamic role for each Client business object. In that case we used and after create event handler on the Client business object.
You can assign dynamic role(s) to user(s) by creating AppUserToRole objects.
Any enforcement based on dynamic role membership would need to be in server side logic. As an example, you could have a before update handler that checks to see if the user is in the role associated to the client row that they are trying to update.