Task Gating & Filtered Task Display on UI

[0x4007]

When this is implemented, we should detect if the user is a collaborator and then only display what they are eligible to start on:

• Collaborator Gating Based On Label ubiquity-os-marketplace/command-start-stop#62

I think increasing coupling between this plugin and this UI is fine because otherwise it is not possible for external DAO contributors to work on tasks. I can't think of another way around this.

1. Check if they are a collaborator of the org
2. If they are not, we need to parse the settings, possibly by exposing an API¹
3. Filter out the tasks they are not eligible for from the UI.

Footnotes

1. We can make a new endpoint on command-start-stop worker endpoint to POST an array of repository IDs (because this can be configured down to the repository level) and then read the config. Is this possible to read the repository configs from a plugin endpoint? Also should we use GET with a header for caching purposes? ↩

[0x4007]

@whilefoo can you think of ways to solve this problem? I don't see how we can read repository command-start-stop preferences from this UI.

[whilefoo]

1. We can make a new endpoint on command-start-stop worker endpoint to POST an array of repository IDs (because this can be configured down to the repository level) and then read the config. Is this possible to read the repository configs from a plugin endpoint? Also should we use GET with a header for caching purposes? ↩

That's not possible because command-start-stop needs a Github token to access the config and tokens are scoped to installations/orgs.
API endpoint in the kernel could read the configs but you need a way to restrict who can call the endpoint and which plugins allow to their config's to be read since they may contain sensitive information.

The easiest way I can think of is for command-start-stop to add a label Collaborator Only on the issue, which makes it simple to filter out eligible issues

[0x4007]

I really don't want to add more labels. I think it's already crowded and imagine when partners have their own labels on top. It will be a mess. However @gentlementlegen suggested embedding metadata inside of the label descriptions which might be the solution.