Add a factory for either an epic or an epic issue
This is useful when we need to test behaviour in epic trees, where an item might be either an epic or an epic issue. Failure to test this assumption means we have code that is silently buggy or can fail at runtime. Some of these issues are discovered here and fixed (notably, reloading the relative position requires custom code for these two classes, since they are queried for in a union). To do this, a new public method is added to RelativePositioning classes: `#reset_relative_position`, which is is called from outside self during `.move_nulls`. Testing improvements: Tests are added for scoped_items and relative_siblings The RelativePositioning system relies on `scoped_items` and `relative_siblings` for many operations. These methods rely on some guarantees about how they include and exclude items. These assumptions are tested here. These changes fix tests that are designed to test for correct behaviour of the relative positioning sibling queries, in particular excluding irrelevant items and the current item. Other changes: - Rename filter_epic_tree_node to epic_tree_node_filter_condition This represents its nature rather better. - Use `Class#underscore` rather than using the table-name, since this is both simpler, and also more resistant to re-naming either of Epic or EpicIssue. - Make all relative positioning methods no-ops on root nodes. Root nodes are not in fact sortable, as they have no relative siblings. Epics at the root node are not sortable, but those contained within the tree are. This change makes it so that all operations on epics at the root node are no-ops. - Restore an exclusivity test that was removed in 304f7212, added after master was broken by a test failure. See: https://gitlab.com/gitlab-org/gitlab/-/issues/247120 Since this is a ~bug fix, we add changelog entry.
Showing
Please register or sign in to comment