Meteor 3 support for v2 branch

[alanning]

Our company is starting to research adding Meteor 3 support to the v2 branch and I wanted to post here in case others had already done any work towards that or would be interested in using the result.

Re: why v2, we prefer the nosql db structure of the v2 branch over the relational-style db structure of the v3 branch.

Goal is not to be feature-complete with Roles v3 or v4. Personally, I'm interested in exploring whether the library could be made to run both inside the Meteor environment and outside for use in Lambda functions, for example.

Any thoughts on making the transition are welcome.

[github-actions]

Thank you for submitting this issue!

We, the Members of Meteor Community Packages take every issue seriously.
Our goal is to provide long-term lifecycles for packages and keep up
with the newest changes in Meteor and the overall NodeJs/JavaScript ecosystem.

However, we contribute to these packages mostly in our free time.
Therefore, we can't guarantee your issues to be solved within certain time.

If you think this issue is trivial to solve, don't hesitate to submit
a pull request, too! We will accompany you in the process with reviews and hints
on how to get development set up.

Please also consider sponsoring the maintainers of the package.
If you don't know who is currently maintaining this package, just leave a comment
and we'll let you know

[jamauro]

@alanning I like this idea. Curious, why'd you close the issue?

[alanning]

Hi @jamauro, since we are updating our app from Roles v1, we have some flexibility in what we do. After taking a closer look at v2 and the parts that we actually use in our app, I felt it would be better for us to just do a minimal update to Roles v1 and keep the API small.

Actually we plan to reduce the exposed functions to only:

userIsInRole
addUsersToRoles
setUserRoles

We will also be changing the DB structure of v1 to allow it to be indexable:

// User object:
{
  ...
  roles: [{
    scope: 'manchester-united.com',
    permissions: ['manage-team', 'schedule-game'],
  }],
}

I had thought v2 used this structure but rather than a permissions array, v2 uses a separate object for each permission.

If you are interested in this minimal version of Roles, let me know and we can release it publicly. Otherwise, we will probably just have it be a private package.

[jamauro]

Cool, even better. I'm interested in a minimal version. My only quick feedback would be:

1. Prefer to keep it as Roles rather than RolesCollection as proposed by the current v4 branch.
2. I did a quick look at my existing usage. I think I would be covered by what you have above except I use:

• getRolesForUser in one place to check for any access without needing to specify all the permissions. One thought here: it might be nice to have something like Roles.hasRole(userId, scope). Maybe you have a better idea here.
• removeUserFromRole to remove permission from a scope. I suppose setUserRoles could fill this gap. Maybe there's already a better way to do this with what you're thinking? Let me know.

[alanning]

@jamauro Sounds good.

Regarding your usage, yes, we can keep getRolesForUser and removeUserFromRole. What's the use case for Roles.hasRole(userId, scope)? If its to check "membership" in the scope, I would recommend having a separate field that controls membership. In our company we've had cases where its useful for people to be considered a member of the org/scope even if they haven't had roles set yet.

Also, do you have code that would use Roles outside of a Meteor environment? For us, we use it both inside the Meteor context on our webservers and also in our AWS Lambda functions. In the AWS Lambda we use a minimal NPM port of Roles which doesn't include any Meteor-specific features: https://github.com/alanning/roles-npm

I'm curious if we could structure this new "tiny-roles" package as a NPM package at its core with a Meteor package wrapper that hooks it into the Meteor Mongo collections...

[jamauro]

@alanning Cool sounds good. Yes, I’m basically using it to determine if they have any type of membership. Thanks for the tip.

do you have code that would use Roles outside of a Meteor environment?

No but I think the approach you mentioned sounds fine. Would be curious to hear how the experience goes. If it’s relatively smooth, I’d imagine others would be interested to hear and could follow a similar strategy where it makes sense with their packages.