Skip to content
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

permissions: add new PermissionIntegrationsService #28400

Merged
merged 15 commits into from
Jan 15, 2025

Conversation

Rugvip
Copy link
Member

@Rugvip Rugvip commented Jan 8, 2025

Hey, I just made a Pull Request!

This adds a new PermissionIntegrationsService that replaces the existing createPermissionIntegrationRouter as well as all extensions points used to add custom rules. It removes the need to manually wire up the integrations router, and also allows for plugin modules to install additional permissions, permission rules, and even resource types.

Naming-wise I've gone with PermissionIntegrationsService for now, but open to other options. Some other ones that I considered:

  • PermissionsIntegrationService
  • PermissionRegistrationService
  • PermissionMetadataService

I figured that keeping "integrations" in there minimizes confusion in the migration from createPermissionIntegrationRouter, and is an alright name for the future too. As for PermissionIntegrationsService vs PermissionsIntegrationService I figured we're dealing with multiple integrations so PermissionIntegrationsService makes more sense, but then again this does look a bit nicer:

permissions: coreServices.permissions,
permissionsIntegration: coreServices.permissionsIntegration,

Thoughts on that? 😁

✔️ Checklist

  • A changeset describing the change and affected packages. (more info)
  • Added or updated documentation
  • Tests for new functionality and regression tests for bug fixes
  • Screenshots attached (for UI changes)
  • All your commits have a Signed-off-by line in the message. (more info)

@Rugvip Rugvip added the area:permission Related to the Permission Project Area label Jan 8, 2025
@Rugvip Rugvip requested review from a team and backstage-service as code owners January 8, 2025 11:33
@github-actions github-actions bot added documentation Improvements or additions to documentation area:catalog Related to the Catalog Project Area labels Jan 8, 2025
@backstage-goalie
Copy link
Contributor

backstage-goalie bot commented Jan 8, 2025

Important

This PR includes changes that affect public-facing API. Please ensure you are adding/updating documentation for new features or behavior.

Changed Packages

Package Name Package Path Changeset Bump Current Version
@backstage/backend-defaults packages/backend-defaults patch v0.7.0
@backstage/backend-plugin-api packages/backend-plugin-api patch v1.1.1
@backstage/backend-test-utils packages/backend-test-utils minor v1.2.1
@backstage/plugin-catalog-backend-module-unprocessed plugins/catalog-backend-module-unprocessed patch v0.5.4
@backstage/plugin-catalog-backend plugins/catalog-backend minor v1.30.0
@backstage/plugin-catalog-node plugins/catalog-node patch v1.15.1
@backstage/plugin-permission-node plugins/permission-node patch v0.8.7

@Rugvip Rugvip force-pushed the rugvip/permission-integrations branch from 7ccf933 to f769700 Compare January 8, 2025 11:38
Copy link
Contributor

@CptnFizzbin CptnFizzbin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking forward to using this 🎉


1. We will be using the `@backstage/plugin-catalog-node` package as it contains the extension point we need. Run this to add it:

```bash title="from your Backstage root directory"
yarn --cwd packages/backend add @backstage/plugin-catalog-node
```

2. Next create a `catalogPermissionRules.ts` file in the `packages/backend/src/extensions` folder.
2. Next create a `catalogPermissionRules.ts` file in the `packages/backend/src/modules` folder.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: since there may be a lot of files related to permissions (and most deployments are likely to have a permission policy), it might be good to encourage grouping things under packages/backend/src/permissions instead of generic 'extensions' or 'modules' folders:

packages/backend/src
+ permissions
  + rules // inventory of all custom permission rules for plugins
  | + catalogPermissionRules.ts
  | + scaffolderPermissionRules.ts
  + policy.ts // App specific permission policy file
  + module.ts // Permission backend module

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd push back on this, ideally you should be creating a dedicated backend module for this and that's been the recommendation. We also have been using the extensions folder in other places in the documentation so this would be a pattern people are following already for smaller things.

In a perfect world I would have had time to finish this PR #27391 that would create a permissions module for you making the docs and process a lot better!

docs/permissions/custom-rules.md Outdated Show resolved Hide resolved
@benjdlambert
Copy link
Member

I was never a fan of permissions integrations 😅 hot take: is there a reason we can't just group this into the permissions service, is there a lot of value in keeping these things separate?

Otherwise permissionRules, or permissionBindings or something?

Copy link
Collaborator

@Parsifal-M Parsifal-M left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks cool 😄 - Maybe I need to read it again tomorrow when I'm less tired, but in the context of the to-do plugin does this really show the benefits of this feature? Or is it worth adding more examples later on perhaps, I probably just need to read the guides in full instead of just the changes 😅

Edit: Ok I see now 👍

Kudos!

@Rugvip Rugvip force-pushed the rugvip/permission-integrations branch 2 times, most recently from 143010a to 0330bc8 Compare January 9, 2025 11:00
@Rugvip
Copy link
Member Author

Rugvip commented Jan 9, 2025

@benjdlambert I kinda like permissionsRegistry, as discussed with Freben so gonna try switching to that. I started out by adding to the permissions service, but it's a very different type of usage so I figured it was best to keep separate. There's also a potential dependency issue where it might be useful to have it be possible for the HTTP router service to depend on the permissions service.

@Rugvip Rugvip force-pushed the rugvip/permission-integrations branch from 0330bc8 to dbed1bd Compare January 9, 2025 11:42
Copy link
Member

@vinzscam vinzscam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is great! Can we see how catalog-backend-module-unprocessed looks like? Asking because it's a corner case where a module brings new endpoints with extra permissions into the plugin. It would be great to see if the new service fits this use case

@Rugvip
Copy link
Member Author

Rugvip commented Jan 9, 2025

@vinzscam absolutely! f45cb90

@vinzscam
Copy link
Member

vinzscam commented Jan 9, 2025

@vinzscam absolutely! f45cb90

🤯

Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
…resource type

Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
…rvice

Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
@Rugvip Rugvip force-pushed the rugvip/permission-integrations branch from f45cb90 to 4e073c7 Compare January 10, 2025 09:06
@Rugvip Rugvip added the merge-after-release This is a bit too scary to merge until after the next release label Jan 10, 2025
Copy link
Contributor

@CptnFizzbin CptnFizzbin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I'll work on updating Scaffolder to use this new service

Copy link
Member

@freben freben left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aight, just little nits, solid work

].map(i => [i.name, i]),
).values(),
);
): express.Router & {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alright, i guess why not - keeps it compatible

Rugvip and others added 3 commits January 14, 2025 17:33
Co-authored-by: Fredrik Adelöw <freben@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>
@Rugvip Rugvip enabled auto-merge January 15, 2025 08:58
@Rugvip Rugvip merged commit 116cd46 into master Jan 15, 2025
32 checks passed
@Rugvip Rugvip deleted the rugvip/permission-integrations branch January 15, 2025 09:17
Copy link
Contributor

Thank you for contributing to Backstage! The changes in this pull request will be part of the 1.36.0 release, scheduled for Tue, 18 Feb 2025.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:catalog Related to the Catalog Project Area area:permission Related to the Permission Project Area documentation Improvements or additions to documentation merge-after-release This is a bit too scary to merge until after the next release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants