-
Notifications
You must be signed in to change notification settings - Fork 80
Add ability to override features for teamtype #6247
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
Conversation
fixes #6222 Adds ability to override - Tables - Instance Resources - Bill of Materials - NPM Packages - Git Integration
|
Picks up defaults from the current team type |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #6247 +/- ##
=======================================
Coverage 76.28% 76.28%
=======================================
Files 394 394
Lines 19805 19805
Branches 4746 4746
=======================================
Hits 15108 15108
Misses 4697 4697
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
For each feature, we need to check the permission checks in the backend to ensure they operate against the Team object and not doing Team->TeamType->Check - as that will fail to apply the team override. For example, the npm catalogue does the check via the TeamType here:
|
This comment was marked as outdated.
This comment was marked as outdated.
|
@knolleary ready for review again |
knolleary
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found a couple places I think the logic needs looking at again.
Also, I spotted the Project.byId function doesn't include properties in the attribute list of the Team it will load - so the overrides will be missing from the object.
|
@knolleary tests are passing again, should be good for a second look |
fixes #4866 Adds a check box to the TeamType config that enables all features. This defaults to enabled for the default team that is create on first startup. Need to decide if we want a migration to enable this for existing installs if there is only 1 team type. This PR is built on top of #6247 and targets it (so it should be merged first).
| result.instanceCountByType = await team.instanceCountByType() | ||
|
|
||
| await appendBillingDetails(result, team, request) | ||
| await updateTeamFeatures(result, team) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Been debugging an odd behaviour with this PR and I think it's due to this line.
This is changing the type object in the response to represent the team-type feature flags with the team overrides applied. Whereas, I think, this should be the underlying team type flags - and the overrides are returned in the top-level properties object for the team.
Still digging into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok -so there are still lots of frontend feature flag checks that are examining the team.type.properties object directly, rather than use the featureCheck composable that would allow us to apply overrides centrally.
Going to look at how quick it would be to switch over.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not a quick switch over. There is a lot of inconsistent use of the featureCheck function and it doesn't cover all feature flags we have.
So I can see why the choice was made to modify the type property. It isn't the ideal solution, but it may be what we have to run with.
| } | ||
| Object.keys(this.editableLimits.features).forEach(feature => { | ||
| // only store the delta from the TeamType |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't working as intended - because the API is modifying team.type.properties.features to include the overrides, this check is not comparing against the underlying type properties.
Working on a fix.
knolleary
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving - but will hold off merge until after the imminent maint release



fixes #6222
Description
Adds ability to override
Related Issue(s)
#6222
Checklist
flowforge.yml?FlowFuse/helmto update ConfigMap TemplateFlowFuse/CloudProjectto update values for Staging/ProductionLabels
area:migrationlabel