feat: support project level custom fields#6736
feat: support project level custom fields#6736Zaimwa9 wants to merge 15 commits intofix/required-metadata-validationfrom
Conversation
…th/flagsmith into feat/support-project-level-custom-fields
…th/flagsmith into feat/support-project-level-custom-fields
…th/flagsmith into feat/support-project-level-custom-fields
|
The latest updates on your projects. Learn more about Vercel for GitHub. 3 Skipped Deployments
|
Docker builds report
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## fix/required-metadata-validation #6736 +/- ##
===================================================================
Coverage ? 98.24%
===================================================================
Files ? 1313
Lines ? 48782
Branches ? 0
===================================================================
Hits ? 47928
Misses ? 854
Partials ? 0 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…:Flagsmith/flagsmith into feat/support-project-level-custom-fields
| migrations.AddConstraint( | ||
| model_name="metadatafield", | ||
| constraint=models.UniqueConstraint( | ||
| condition=models.Q(("project__isnull", True)), | ||
| fields=("name", "organisation"), | ||
| name="unique_org_level_metadata_field", | ||
| ), | ||
| ), | ||
| migrations.AddConstraint( | ||
| model_name="metadatafield", | ||
| constraint=models.UniqueConstraint( | ||
| condition=models.Q(("project__isnull", False)), | ||
| fields=("name", "organisation", "project"), | ||
| name="unique_project_level_metadata_field", | ||
| ), | ||
| ), |
There was a problem hiding this comment.
I'm not sure this is compatible with Oracle. Is it a requirement ?
There was a problem hiding this comment.
IIRC, we're not supporting Oracle moving forwards in code. I'd defer confirmation to @matthewelwell.
There was a problem hiding this comment.
We are a while away from dropping oracle support so we'll need to consider it still.
There was a problem hiding this comment.
So my findings are that Oracle silently skips UniqueConstraint and the constraint is not enforced at the database level.
It seems that it's already a pattern that we've used in previous migrations e.g:
- FeatureState
- Release pipeline feature versioning
- And older in LD importer
So the support is not optimal for Oracle but still compatible, if ever you have some thoughts on this @gagantrivedi ?
Wouldn't it be less confusing to not allow conflicts? |
I do remember asking the question while grooming and we agreed on allowing re-creating the custom fields at project level. What Gagan suggests is to simply forbid and return an error if the name already exists in the organisation (be it project/org level) |

Thanks for submitting a PR! Please check the boxes below:
docs/if required so people know about the feature.Changes
Closes #6620
Support project scoped custom fields which could only be defined at organisation levels
MetadataFieldunique_togetherwith conditionalUniqueConstraints_validate_required_metadataaccepts project paramis_required_forfetched and included in responses directly (replacing 2 different requests made in the frontend => coming in next branch)New endpoint
?include_organisationto include inherited org-level fields (calculates the precedence for project in case of conflicts)?entity=feature|segment|environmentto only return fields of the given identity (simplifies the creation of the identity)In case of conflicting name, project custom fields takes precedence and org ones are skipped
How did you test this code?