-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RoleSet + Role: shareable role management #4544
Conversation
Important Review skippedMore than 25% of the files skipped due to max files limit. The review is being skipped to prevent a low-quality review. 63 files out of 157 files are above the max files limit of 75. Please upgrade to Pro plan to get higher limits. You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
…ating subspace partially
…wo, with one for public + one for protected fields
The key goal of this PR is to
a) make the management of a set of roles re-usable
b) have the set of roles to be data driven, not hard coded
For the former there will need to be later work to make the events based on role changes to be done actually via events, so that different listeners can hook onto them.
For the latter we do still have with this PR the same set of roles (member, lead, admin) but they are now entries in the RoleSet so we can relatively easily from here expand the set (e.g. communityManager, processGuide etc).
This PR should be seen as setting the base for having a single way of managing Roles across multiple contexts (Platform, Org, Community), as well as allowing for much more flexibility in the set of roles that are used (data driven, not hard coded). On the client this will also allow for one set of controls for working with roles.
RoleSet entity:
Client is updated in that codegen is running and there are no compilation errors.
Community no longer has a pointer to its parent Community.
Todo:
After all is running check if community still needs to know its parent, either via ORM relation or via ID
Out of scope for this PR:
Removed
For reference, the old community policy JSON:
which now looks like:
So the data is now much more structured in the db.