docs: Add project-level import/export specification#7114
docs: Add project-level import/export specification#7114
Conversation
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code review is billed via overage credits. To resume reviews, an organization admin can raise the monthly limit at claude.ai/admin-settings/claude-code.
Once credits are available, reopen this pull request to trigger a review.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
Prettier was mangling `{/* */}` into `{/_ _/}` which Docusaurus
interprets as a regex literal, breaking the build.
beep boop
- Wrap excluded data list in caution admonition - Add "How entities are matched" section (by name, not ID) - Add permission requirements (project admin for export, org admin for import) - Remove backward-compatibility claim for env-level format in project import beep boop
Remove custom fields/metadata and integration configurations from the optional export data table. Neither has schema or serializer support defined yet. Can be added as follow-up issues. beep boop
| - **[Environment-level](#environment-level-export)**: export and import default feature states for a single environment. | ||
| Useful for quickly copying feature values between environments or projects. | ||
| - **[Project-level](#project-level-export)**: export and import an entire project's feature configuration, including | ||
| segments, segment overrides, and optionally identity overrides and tags. Useful for cloning a project or migrating | ||
| between Flagsmith instances. |
There was a problem hiding this comment.
While I think we can get away with this separation, it's not 100% correct I don't think.
What we're terming the 'Environment-level' import here does include information from the project. It was built as a 'Feature' export, so it includes information about the default value of the flag. As I understand it, this is what is used in a destructive import - it will overwrite other environments with the default value.
Perhaps the scope of this documentation update also covers reviewing and improving the 'Environment-level' import if we can, since this behaviour is not desirable anyway...
There was a problem hiding this comment.
Does 710d34e make sense to you?
Also, to clarify, do you think we should amend the 'Environment-level' import behaviour as part of the epic?
There was a problem hiding this comment.
Also, to clarify, do you think we should amend the 'Environment-level' import behaviour as part of the epic?
I would love to.
The ideal scenario here in my head is leave the documentation as you had it, and 'fix' the current behaviour which affects other environments on import. That being said, I can't remember why we had to implement it that way in the first place. I do think there was a technical reason for having to affect other environments.
There was a problem hiding this comment.
Filed it as a bug here #7166, and reverted the docs fixup. Up to us to add it to the epic, but since there's no dependencies, I'm keeping it separate for now.
docs/docs/administration-and-security/data-management/bulk-import-and-export.md
Outdated
Show resolved
Hide resolved
| instances. Specifically: | ||
|
|
||
| Since a feature may have an identical name, it is important to carefully select a merge strategy during a feature import. | ||
| - Features and segments are matched by name. |
There was a problem hiding this comment.
We should be careful here - I have a feeling we don't enforce unique segment names?
There was a problem hiding this comment.
I wonder if we should again just swallow more scope as part of this work...
There was a problem hiding this comment.
The dependency is only there because we added a clarification to the docs, I think?
Come to think of it the "first matched" behaviour shouldn't mean any special code really.
There was a problem hiding this comment.
I guess our options are:
- Keep the docs change added in 539906d which reflects the behaviour if we do nothing
- Revert the docs change added in 539906d and bring Duplicate segment names allowed, causing confusion during linking #5489 into the relevant epic
- Revert the docs change added in 539906d and just accept that there's a bug as per Duplicate segment names allowed, causing confusion during linking #5489
IMO, since #5489 is fairly trivial, I'd like to go with option 2 here, but I'm happy to go with any of the options.
Address review feedback — the previous wording ("default feature states
for a single environment") was misleading since the export also includes
project-level feature defaults.
beep boop
Segment names are not enforced as unique per project. Document the matching behaviour for duplicates: first match in target project, all imported from export. beep boop
This reverts commit 710d34e.
This reverts commit 539906d.
2 participants
docs/if required so people know about the feature.Changes
Contributes to #6761
In this PR, we document the planned project-scoped export/import feature alongside the existing environment-level bulk import/export. This serves as the specification before implementation begins.
Key changes to
bulk-import-and-export.md:import-and-export.mdindex page now references both levels.Preview links
How did you test this code?
Documentation-only change. Verified formatting with
npx prettier --checkand Vercel preview build.