Landingzones UI and workflow overhaul

[mikkonie]

There are many open ideas and questions about the landingzones UI and general workflow. In my opinion we should go through them all at some point and decide how everything should work in the future, what to implement and when.

Open Issues

• 57: Allow read access in Landing Zone for another user

• 159: Add async updating to all activity

• 321: Explicitly declare which state of a zone is "locked"

• 397: Add UI functionality to clean up invalid zones

Bugs Etc.

• 269: Urlpatterns exception in plugins

• 305: Occasional freezing of async status/stats updates

Other Open Questions

• Should we keep showing "other zones" for admins and project owners/delegates?
  • Should be useful for them to know what's happening
  • Is the current style of displaying them too confusing?
• We currently show Davrods and iCommand links for other users' landing zones even if the owner user can't actually access them in iRODS
  • Remove links if in landing zones?
  • Or, give access to owner/delegate?

TBD: Any other open issues/suggestions?

[mikkonie]

Idea

• Instead of having a single webpack bundle for the samplesheets vue app, implement Vue stuff as a common SODAR bundle
• Use single bundle to implement Vue.js frontends for SODAR-specific apps (samplesheets, landingzones, irodsbackend)
  • Yes, some or even all of these would still also have Django-based server side visualization. Irodsbackend definitely
• Re-implement the landingzones UI using Vue.js and the paradigms in the new samplesheets app
• Move the current iRODS buttons used in the samplesheets vue app into general irodsbackend vue components usable by all apps

-> Synergy! Consistency! Profit!

This, of course, will happen some time after v0.5 as the samplesheets and the editor are a top priority. That said, reworking the rather simple Landingzones UI as a Vue app should not be a huge task with accumulated experience.

Comments? Ideas? Anyone actually reading this? (probably not)