Allow for different knowledge view trees for different bases

[AJamesPhillips]

Currently

• A knowledge view has a single parent knowledge view id. When you use it in a different base it is not possible to nest it within that knowledge view tree without destroying it's position in the knowledge view trees of other bases.

Description (acceptance criteria)

Option 1

• [ ] Editing the parent knowledge view id should only occur in the base which owns it.
• [ ] Other bases should have a base specific knowledge view entry

Option 2 (prototyped on this base_knowledge_view_tree branch)

• [x] add knowledge_view_tree json field to the bases table
• [x] write function that transforms the existing set of knowledge_view.parent_knowledge_view_id to the new base.knowledge_view_tree
  • [ ] The knowledge_view_tree has the same single-link structure from child to parent (the current prototype has the parent having multiple children. This would allow for the same knowledge view to be emdeded in the tree at multiple points however this then complicating routing params as the subview_id would then need to be a path of ids otherwise if a knowledge_view with id 123 was under a knowledge view with id 456 and another with 789, currently it would not be possible to tell through which path the knowledge view was being selected. I think the ability to have multiple instances of the knowledge view in the knowledge view tree is not yet necessary so keep with the simpler implementation for now of children pointing to their parents.
• [ ] Find all the derived states needed and implement them.
  • [ ] 1. need to render the breadcrumb and given the current kv_id, needs to provide:
  • the path of selected knowledge views
  • and their sibling knowledge views (if any)
  • and have these sibling knowledge views sorted by sort_type & title and filtered by sort_type, e.g. priority and normal with errored, archived and hidden not present
  • and the unselected child knowledge views (if any) of the currently selected kv
  • [ ] 2. needed for the "Nest under" option when editing a knowledge view's nesting
  • a list of all knowledge views contained in the current knowledge view tree that it can be nested under
  • [ ] 3. needed for specifying which knowledge views can be present at the top level
  • no derived data is needed here but when this option is used on a knowledge view from this base or another base, then it is added to the top level of the new knowledge_view_tree
  • [ ] 4.
• [ ] knowledge_view.parent_knowledge_view_id will be removed

Also would need to add:

• [ ] Bases need to have concurrent write protection
• [ ] Editors also need to be allowed to edit base (but not access controls for now)

Decide on what happens when:

• [ ] Transferring a knowledge view and its nested knowledge views to another base needs to edit the other base's knowledge_view_tree (whilst providing option to keep entries in current base or delete them)

Why (hypothesis)

• Will stop an author of a base having their knowledge view tree changed by others incorporating their bases' components into their own base
• Will allow for a knowledge view to be present in the knowledge view tree of multiple bases