Although this gets more into a "philosophical" discussion: in your concept is some meaning in the RoleID (RoleID <= 20 means Standard Role etc.). This is something I would avoid, because an ID is just an ID. Using the RoleName is much more the way to go, eg.

UserInfo.IsInRole(string roleName)

So you have to flag the "Standard" roles in some way, that they cannot get deleted or renamed by the customers, as some logic from your side relays on them. And there is something in DNN to reach this, and this is the IsSystemRole property of the RoleInfo object. Just set it to true when you create the role.

Hope that helps.

Happy DNNing!
Michael

I fully agree with your observations.
But the DNN DB is structured in order to relate the PKs of the objects, as it should be.
In a purely functional context, there is no other way than to rely on the name of the role, which in fact establishes its purpose.
But if we go down one level, I have to consider that DNN objects are assigned visibility (or not) to the role with a certain ID, because in fact it is the data persisted in the database.

PS: the customer cannot modify anything of the standard, he can only add: roles, users, objects, etc...

Thanks
S.

Honestly, I think this is indeed possible, but it would be pretty hacky and would require a custom RoleProvider is created to handle all of these things.  Though, even with all of this work, you'll have weird bugs that you'll just have to deal with.  This is because the rest of DNN uses IDs/PKs differently than your app intends to.  

However, to avoid these kinds of "workarounds" in the past, we've simply implemented logic around the naming convention of Role Names, as Michael suggested.  

Thanks Will,
if customer create custom roles, how can i know:
1) Their names?
2) What objects they enable?
3) Which users are assigned to?
From the database and its relationships.

Before each update I save the customer's custom data, but repopulate them in the db after the update (yes, in fact I'm going to replace it with that of the updated version...) at the moment it is only possible by going through the DNN API.

RoleController.Instance.AddRole

Which results in a new id being assigned to an old role that is already set to existing objects that I don't have direct control over.

So you're referring to implementing a RoleController instead of a RoleProvider?

Sorry for my noobish questions.

Thanks
S.

Posted By Seek on 8/10/2023 5:02 PM

Thanks Will,
if customer create custom roles, how can i know:
1) Their names?
2) What objects they enable?
3) Which users are assigned to?
From the database and its relationships.

ad 1) and 3): There are three tables, Roles, Users and UserRoles. The names of the roles can be found in the Roles table ("RoleName"), and the users assigned are in the UserRoles table. Eg, to find all users in the Administrators role, you can use this statement in the SQL Console:

SELECT
  r.RoleName,
  u.FirstName,
  u.LastName,
  u.Username,
  u.Email
FROM
  dbo.Roles r
  INNER JOIN dbo.UserRoles ur ON ur.RoleID = r.RoleID
  INNER JOIN dbo.Users u ON u.UserID = ur.UserID
WHERE
  r.PortalID = your_portal_id AND
  r.RoleName = 'Administrators'

ad 2) I think the relevant tables are Permission, PortalPermission (PortalID from Partals), TabPermission (TabID from Tabs), FolderPermission (FolderID from Folders) and ModulePermission (ModuleID from Modules), maybe there are some more in your usecase (PersonaBarPermission, ContententWorkflowStatePermission, and others related to some third party modules like ActiveForums_Permissions etc.), but it's quite easy to explore.

Happy DNNing!
Michael

Posted By Seek on 8/11/2023 9:35 AM
Additional question: how to correctly load/inject a RoleController/RoleProvider instead of default one?
I'm working on DNN 7.4 (but I'm slowly migrating to 9.11.02 :-D)

Thanks
S.

The role provider is defined in the web(dot)config, the original entry is

{roles defaultProvider="DNNRoleProvider"}
  {providers}
    {clear /}
    {add name="DNNRoleProvider" type="DotNetNuke.Security.Roles.DNNRoleProvider, DotNetNuke" providerPath="~\Providers\MembershipProviders\DNNMembershipProvider\" /}
  {/providers}
{/roles}

(use < and > instead of { and })

Happy DNNing!
Michael