Filter out epic's notes that can not be exported
What does this MR do and why?
Related to #384265 (closed)
When exporting a group that contains cross-group child epics (i.e. epics with children from different group hierarchies) they could include notes that are not visible to the user.
To be able to filter readable notes when exporting the group's resources, this MR introduces a new Exportable
concern that can be included in the resource's model and provides authorization for the resource associations.
Important notes:
- The authorization relies on
#readable_by?
being defined for the association as well as the corresponding policy - If special permission is required,
#exportable_record?
should be defined in the association's model. This method will take priority over#readable_by?
. - The change in behavior affects only resources that include
Exportable
and define#exportable_restricted_associations
containing associations being exported (i.e. included inimport_export.yml
) - The concern also provides the method
#exportable_association?
used for conditional export - Cross-group epics feature is still in development and behind the feature flag
:child_epics_from_different_hierarchies
Screenshots or screen recordings
Example epic with cross-group notes (exporting user has no access to External Group)
Exporting user view | External Group owner view |
---|---|
How to set up and validate locally
- Enable the Feature Flag for cross-group child epics
Feature.enable(:child_epics_from_different_hierarchies)
- With a non-admin user (
@user_a
) create a group (My Group
) and two epics (My Epic
andMy Child Epic
) - With a different user (
@user_b
) create a new private group (External Group
) with an epic (External Epic
) - Add
@user_b
toMy Group
asReporter
- Signed in as
@user_b
visitMy Epic
and addExternal Epic
as a child epic - Signed in as
@user_a
visitMy Epic
and addMy Child Epic
as a child epic, the current user should only see the system note mentioningMy Child Epic
- Visit the group settings
http://gdk.test:3000/groups/my-group/-/edit
and export the group in theAdvanced
section - Download the export file and find
epics.ndjson
insidetree > groups > 192
directory - Ensure the notes association contains only one note with the text
"added epic \u00262 as child epic"
See example with json files exported before and after this change.
Tested Scenarios
With existing settings
- Epic with an inaccessible parent
- Only shows accessible notes
- Does not include the parent field (due to conditional export)
- Epic with an accessible parent
- Shows the parent field
- Epic with inaccessible child epic
- Only shows accessible notes
- Issue with inaccessible epic
- Does not include the epic_issue field (due to conditional export)
- Issue with accessible epic
- Shows the epic_issue field
With hypothetical settings
Example 1: Conditionally export the field label_links
for issues
When using an association that doesn’t have a policy we get an error that is sent by email:
Project Test Project couldn't be exported.
The errors we encountered were:
no policy for LabelLink
After adding a policy or defining exportable_record?
in LabelLink
:
- Issue where all
label_links
are inaccessible- Does not include the field
- Issue with accessible
label_links
- Includes the field
- Issue with empty label_links
- Include the field with value
[]
- Include the field with value
Example 2: make epic_issue
a restricted association for issues (instead of a conditional one)
- Issue with inaccessible
epic_issue
- Includes field and shows value
nil
- Includes field and shows value
- Issue with accessible
epic_issue
- Includes the field with the record
- Issue with no
epic_issue
- Includes field and shows value
nil
- Includes field and shows value
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.