Skip to content

Conversation

@hardillb
Copy link
Contributor

@hardillb hardillb commented Nov 5, 2025

fixes #6222

Description

Adds ability to override

  • Tables
  • Instance Resources
  • Bill of Materials
  • NPM Packages
  • Git Integration

Related Issue(s)

#6222

Checklist

  • I have read the contribution guidelines
  • Suitable unit/system level tests have been added and they pass
  • Documentation has been updated
    • Upgrade instructions
    • Configuration details
    • Concepts
  • Changes flowforge.yml?
    • Issue/PR raised on FlowFuse/helm to update ConfigMap Template
    • Issue/PR raised on FlowFuse/CloudProject to update values for Staging/Production
  • Link to Changelog Entry PR, or note why one is not needed.

Labels

  • Includes a DB migration? -> add the area:migration label

fixes #6222

Adds ability to override
- Tables
- Instance Resources
- Bill of Materials
- NPM Packages
- Git Integration
@hardillb hardillb self-assigned this Nov 5, 2025
@hardillb
Copy link
Contributor Author

hardillb commented Nov 5, 2025

image

Needs test

@hardillb
Copy link
Contributor Author

hardillb commented Nov 5, 2025

Picks up defaults from the current team type

@codecov
Copy link

codecov bot commented Nov 5, 2025

Codecov Report

❌ Patch coverage is 92.24138% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 76.28%. Comparing base (c3beb87) to head (ae0f715).
⚠️ Report is 7 commits behind head on main.

Files with missing lines Patch % Lines
forge/lib/features.js 0.00% 3 Missing ⚠️
forge/ee/routes/customHostnames/index.js 0.00% 2 Missing ⚠️
forge/ee/routes/gitops/index.js 0.00% 2 Missing ⚠️
forge/ee/routes/teamBroker/schema.js 0.00% 2 Missing ⚠️
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           
Flag Coverage Δ
backend 76.28% <92.24%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@knolleary
Copy link
Member

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:

if (!teamType.getFeatureProperty('npm', false)) {

@hardillb hardillb marked this pull request as draft November 5, 2025 14:12
@hardillb

This comment was marked as outdated.

@hardillb
Copy link
Contributor Author

@knolleary ready for review again

Copy link
Member

@knolleary knolleary left a 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.

@hardillb
Copy link
Contributor Author

@knolleary tests are passing again, should be good for a second look

hardillb added a commit that referenced this pull request Nov 26, 2025
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)
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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
Copy link
Member

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
Copy link
Member

I've pushed a UI rework for the edit dialog:

image

Including an indicator for any applied overrides:

image

As noted in my inline comments, I think there is a big tidy up needed in how feature flags are checked in the frontend. We have lots of places access team.type.properties directly - which has meant this PR is mutating that object to apply the overrides. It would be much clearer for team.type to be unchanged, and for the frontend to provide a central place to do feature checks. That central place does exist for some flags, but not used consistently. I will raise an issue to address that, then we can revisit the change made by this PR.

Copy link
Member

@knolleary knolleary left a 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

@hardillb hardillb merged commit f69e838 into main Dec 10, 2025
20 checks passed
@hardillb hardillb deleted the more-team-overrides branch December 10, 2025 10:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Enable TeamType overrides

3 participants