Restricting Blueprint access based on User Tiers

[MarianRaphael]

Epic

https://github.com/FlowFuse/flowfuse/issues/2828

Description

As a: FlowFuse Admin I want to: Restrict specific Blueprints to specific Tiers So that: Only users belonging to higher Tiers, such as Teams and Enterprise, can access selected Blueprints

Which customers would this be availble to

Team + Enterprise Tiers (EE)

Acceptance Criteria

• [ ] Config option in the Admin panel for the Flow blueprints

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

[Steve-Mcl]

Config option in the Admin panel for the Flow blueprints

• Is this option to be a table of existing tiers with a checkbox next to each (e.g. show/hide this blueprint in xxxxx tier)?
• Should, by default, all tiers be checked (i.e. show on all tiers as a default)?

[knolleary]

Team Tiers don't have a concept of order, so we don't have a short-hand way of saying 'Team or higher' for example. So a checkbox list is probably the way to go. To avoid cluttering the already cluttered dialog, I'd suggest a select box with options 'available to all teams' and 'available to selected teams' - and only show the list of checkboxes if the second option is selected.

I would also default to 'available to all'

[Steve-Mcl]

Weighing up the work for adding a check list vs introducing a kind of "ordering" on the team tiers I see the following work loads: adding tier ordering is a much smaller task.

check list:

• A link table for each blueprint to tier as visible/not visible
• Backend CRUD for managing entries
• Front end work for table display and edit

team tier ordering

• An order field in the DB table
• An "Available To Team" field in blueprint table
• A number spinner in the team tier

Do we want to consider that route first?

[knolleary]

There may be bigger consequences to introducing ordering of the team tiers. I would recommend not going that route today.

For the checklist approach, this doesn't require any new apis, it'll just be a property of the blueprint that lists the team tiers it is available to. The main part is designing how that information is stored so that it can be queried easily.

The existing list blueprints api does not know anything about the context of the team making the query. So the endpoint will still end up returning all active blueprints. I'd suggest adding an optional filter parameter to the end point to return just those blueprints available to a given team tier.

The 'Create Instance' apis will need to also validate the blueprint is available to the team.

[Steve-Mcl]

it'll just be a property of the blueprint that lists the team tiers it is available to

As in a JSON field (array) that lists allowed teams (defaulting to "allowed" if not explicitly present)?

That certainly would scope this down compared to a many-to-many table relationship between teamtypes and flowtemplates.

@knolleary ^

[knolleary]

@Steve-Mcl that would be my starting point unless there was a compelling reason to do it via through-tables. We can always move to a more db structured approach in the future if necessary.

[hardillb]

Verified on stagine