Giant collections needed on page copying

[Catherine Johnson]

Collections which are navigation blocks on a page should allow copying and editing of the collections

[Kristina Hoeppner (kris-hoeppner)]

To expand a little bit on what Catherine means:

She has several collections that are all linked to each other. The navigation block is used to put links from collections A and B into collection 1. Collection 1 basically serves as super collection of which collections A and B are children.

When she copies collection 1, the navigation blocks are copied, but when the links are clicked, they lead to the original collections A and B of the user from whom collection 1 was copied. Ideally, she would like to have collections A and B copied along as well. Kind of like when you use the blog post block where you can decide whether a user who copies the page doesn't get anything, only sees the blog posts or gets their own copy of the block posts.

[Richard Mansfield (richard-mansfield)]

See also the related bug #898923, which fixes the copying problem for navigation blocks within a single collection.

I recently commented on a similar request to this via email, so I'll add my opinion on this bug report too.

I'd prefer to see the "giant" collections feature addressed by implementing something more along the lines of the "multipage views" specifications here:

https://wiki.mahara.org/index.php/Developer_Area/Specifications_in_Development/Multipage_Views
https://wiki.mahara.org/index.php/Developer_Area/Specifications_in_Development/Multipage_Views_Take_2

Those are just ordinary collections, like we have at present, except that you can create hierarchical navigation between pages in a collection, rather than just a flat list.

The advantage of doing it that way is that we already have existing code for copying collections, and for ensuring all pages inside a collection have the same access rights. Adding another layer for collections of collections would (a) require reimplementing all that work to keep everything sane at the higher level, and (b) unnecessarily restrict the number of levels in the collection navigation menu to two.

Navigation blocks should probably never have been allowed to point to any collection apart from the one they're inside, because this leads to broken links if users aren't careful - it allows navigation blocks to point at deleted collections or collections with different access rights to the one containing the navigation block. Penny's specification for multipage views makes that point too - she says navigation blocks don't need to be configurable at all (they just automatically create navigation for the collection they're in). Unfortunately it's a bit late to change this now without annoying the people who are using it as a workaround.

Rather than creating a second explicit level of collections, the other possibility hinted at in this bug report is to make "giant" collections implicit, by doing some magic during collection copying to find and follow all the navigation blocks, and copy any additional collections that are pointed at in those blocks. However, this has all the problems with inconsistencies in the access rights, navigation blocks for deleted collections, and navigation blocks pointing at other peoples' collections due to bug #898923. It also creates additional work in the UI to let users choose whether they want to copy a single page on its own, or an entire collection, or the "giant" collection. It also seems wrong to make the existence of a navigation block on a particular page imply something about which collections are contained within other collections.