I have a long time headache with “strange” Meteor.Roles logic. The first BIG disadvantage is, that Roles does not support “role” in right word meaning, but only “permission”. Therefore, in my case I need:
ROOT level roles (as roles) and child roles (as permissions)
In my case I need also child permissions (it’s just example):
ADMIN1
– settings
— settings.view
But now, I need also ADMIN2 with the same roles and now the situation starting to be BAD:
I can do by the following way:
ADMIN1
– ADMIN2
— settings
---- settings.view
…but this is incorrect way I think, because If I will need later add ADMIN3, all child settings we need to manually move under ADMIN3 (in some cases, this is complicated and risky, because we can lost permissions during this movement, which can couse problems).
Therefore, I tried to implement another option:
ADMIN1
— settings
---- settings.view
ADMIN2
— settings
---- settings.view
ADMIN3
— settings
---- settings.view
…and here, I’m starting my fight For the Meteor it is OK, but for the datagrid it’s a big problem, because “settings” and “settings.view” childs is same item with same _id and this is big problem for datagrids. Why the Meteor.roles is storing role alias into _id (I know, It’s probably prevention between same roles multiple time, but is it required)?
I’m implementing datagrid with dynamically loading child items, with searching, sorting and filtering, but non-unique _id is impossible to use. Do you have same experiences like me? How did you solved this problem?
I don’t really understand your requirements but I think Meteor Roles (alanning:roles) has feature which is roles management like its name.
In order to work with permissions, you will need to provide your own logic. I personally prefer ts-access-control package which allows to define resources and permissions (create, update, read, delete).
Hello @minhna thank you for your answer. If name if item is “role” or “permission”, problem is still the same. To make it more clear, “final” problem at the end is, that all datagrids require unique “id” to identify each datagrid row. As Meteor.roles (or “alaning:roles”) are designed, It is not possible to ensure (in case, when single same permission is assigned into multiple parent permissions).
ts-access-control is great recommendation, but I’m affraid, that it is not support “scopes” (or something similar), which I’m later thinking to use in my tenant architecture app.
@minhna yes, of couse. But the id for each row must be unique. I tested lot of ways, at the end, none was corrent because at the end, I always found some limitations
Now, I made rollback and I dropped some of my demands and only what I didn’t tried yet (new idea) is modify _id on client side (only for datagrid) and add some random suffix <_id value>__<suffix random value (Meteor.id() hash> to make ids unique an then in custom method getRowId remove suffix before return id value.
I too use alanning:roles package (or actually a derived one pwix:roles but basically the same for the sake of this discussion), and I have written pwix:permissions to handle the rather common case where a permission is computed from userid (if any) + scope (in a multi-tenant application) + anything depending of the required permission.
Permissions are named, and associated with a function. It is up to the requester to provide its own parameters to the functions. This way, permissions are computed not-only based on user roles and scope, but also with any arguments provided by the requester.
thank you very much for your package and recommendation. After my experience of migration to Meteor 3.1, when I had lot of “headache” with fixing very old and deprecated dependencies in (not mine) meteor packages, I’m prefer using dependencies in mine own package.json and using Meteor packages with as few dependencies as possible or features directly integrated into Meteor, which will be probably better maintained in the longer future. This is the reason, why I’m not searching an “improved alternative fork” of meteor roles, but I’m searching some way, how to implement it in “it’s original version/login”.
I leaved from some, of my expectations, for example from dynamic loading of child items (I will load it all together), but “only” what I must solve now is non-unique role ids, when single row is used multiple times.
@pwix Can I have a question please? How you are using roles with your tenant app? Are you combine “global” defined roles valid for all tenants with those roles defined fom tenants? Or only global roles? Or only tenant roles?
Yes, some roles can be scoped and apply to the considered tenant only. But they are (at least in meteor-roles, and so in pwix:roles) globally defined.
Actually, I didn’t have yet a use case for per-tenant role, and only make use of global roles. In all apps I have coded (or participated to), roles could be viewed as some kind of permissions for features, and features were globally defined. Whether a tenant wanted this feature or not being another story
In pwix:roles, we define roles at initialization, and maintain a hierarchy. as you can see in roles.js, some roles are globals while others are scoped (though globally defined)
Still in izIAM for example, some permissions are defined in permissions.js.
Looking at it, we see that each function which wants be authorized has to defined its unique name which is the name of the permission, then asks the pwix:permissions if it is allowed for current user, scope, object and so on…
See also accounts-manager-permissions.js or app-edit.js, or others in this same directory.
This is not a revolution at all, just a way to centralize all these user/scope/object-dependant computings on whether someone is able to do something.
Hope that this is clearer ?
For the Meteor it is OK, but for the datagrid it’s a big problem, because “settings” and “settings.view” childs is same item with same _id and this is big problem for datagrids. Why the Meteor.roles is storing role alias into _id (I know, It’s probably prevention between same roles multiple time, but is it required)?
