Refactor sidebar logic into reusable component

[mikkonie]

In #1366, we have a use case for providing sidebar content via an Ajax view to e.g. client-side single page apps. This enables them to display the sidebar content as they choose, without requiring the use of base SODAR Core templates.

Right now, the logic for building the sidebar is completely contained in the _project_sidebar.html template and associated template tags. We should move the logic away from the template and provide the necessary data as a reusable helper component. That enables us to both render the list in the server-side template in SODAR Core, as well as provide it to client-side SPAs via the Ajax view.

Where to place the new helper turned out to be a somewhat complex issue. Having this as a context processor would not be optimal, as retrieving e.g. the project context there would be tricky. Also, this would create a very spagetti-ish processor method. My next idea was to extend ProjectContextMixin, but this would not correctly build the sidebar for site app views or the home view. The only 100% common factor between these views is the sidebar template, so we should still retrieve the list data via a template tag. But of course a template tag should not be used to add data into an Ajax view.

In the end, the following solution seems to make the most sense:

1. Add new utility class to build sidebar links
2. Move logic from template and template tags into utility class
3. Wrap utility class back into a single template tag
4. Render list in template based on data returned from utility class

Spec

• Add AppLinkContent class to projectroles.utils
  • Why utils? Because it's not a mixin as we also have to access it directly in template tags.
  • Why a class? Because otherwise we're setting ourselves up for circular dependency hell.
  • This also will be used for the user dropdown links (Refactor user dropdown logic into reusable component #1381)
• Add method get_sidebar_links()
  • Args should be:
    • request (HTTPRequest object)
    • project=None (Project object or None)
  • This should return a list of dicts with each dict containing the following:
    • url: URL for the link
    • label: Text label to be displayed
    • icon: Icon to be used in format of namespace:id, e.g. mdi:home
    • active: Boolean for whether the link should be currently highlighted as active
• Move sidebar logic from template and template tags to new class
  • Project context checks, perm checks, visibility checks, state/activity checks, etc
  • Goal: all logic happens within get_sidebar_links() (and potential internal helper methods in the new class)
  • The method simply returns a list of links valid for the current view and user
• Add wrapper template tag in projectroles_tags to retrieve sidebar list
  • Call the template tag to retrieve the links into the template
    • Pass project from view context to parameter (will either be an object or None)
  • Still use values from sidebar_processor.py
  • If all goes well, the list should look and behave exactly like before
  • Existing UI tests should help detect if something goes wrong, see e.g. TestProjectSidebar
    • ..but feel free to improve tests if something is missing!
• Refactor _project_menu_btn.html similarly
• Add tests for new helper class
  • Hint: feel free to copy from tests of the old template tags
• Remove any template tags which are no longer used after this change
  • Also remove their tests

Tasks

• Add new helper class
• Move sidebar logic from template, template tags and context processor into class
• Use class to render sidebar via a wrapper template tag
• Deprecate sidebar_processor
• Remove unused template tags (if any)
• Update tests

[mikkonie]

Done by @gromdimon, merged.