User Dashboard should be configurable enough for reusing in Hosted Che

[ibuziuk]

Is your task related to a problem? Please describe.

Currently, on Hosted Che side we do a few UD related changed in comparison with upstream. I think now after reorg it is a good time to get rid of the rh-che specific changes and make UD generic / configurable enough to be fully reused in the downstream.

Motivation

Every sprint the Hosted Che team spent time for backporting changes from upstream to downstream. For example 7.5.1 related updates - redhat-developer/rh-che#1722

What needs to be done

It looks like we can relatively easily get rid of the Hosted Che specific changes:

• Hosted Che disables "Organization" Tab - https://github.com/redhat-developer/rh-che/blob/814f15e4dfb0e99d6a2e476743574d49796ce58f/assembly/fabric8-ide-dashboard-war/src/app/organizations/organizations.html
  It should be possible to disable menu items on demand in the upstream (as a developer I want to have an opportunity to disable some menu items via properties)

Also, the "Organization" concept might be soon deprecated upstream - #15304 (comment)

• Disabling Workspace sharing - https://github.com/redhat-developer/rh-che/blob/814f15e4dfb0e99d6a2e476743574d49796ce58f/assembly/fabric8-ide-dashboard-war/src/app/workspaces/share-workspace/share-workspace.html
  This option should be configurable upstream (I think this might be also interesting for CRW in some cases)

• Ephemeral toggle on Create Workspace screen - https://github.com/redhat-developer/rh-che/tree/3579c2a1618d60980be0533a6d8680a268c5b305/assembly/fabric8-ide-dashboard-war/src/app/workspaces/create-workspace

I think it should be contributed to the upstream and it should be disabled by default. There should be a configuration option to enable in the upstream

• Adding FAQ link to footer - https://github.com/redhat-developer/rh-che/blob/master/assembly/fabric8-ide-dashboard-war/src/components/widget/footer/che-footer.html

This should be done in upstream. Also, we can have the same FAQ file for Eclipse Che and Hosted Che in the docs coming one after another. Related issue - redhat-developer/rh-che#1479

• Pre-fetching of the default editor CDN resources - https://github.com/redhat-developer/rh-che/blob/3579c2a1618d60980be0533a6d8680a268c5b305/assembly/fabric8-ide-dashboard-war/src/components/ide-fetcher/che-ide-fetcher.service.ts
  Should be contributed upstream

• Disable View&Change Kubernetes Target namespace on Create Workspace and Workspace Details page (It should be done with different options)

Describe alternatives you've considered

Hosted Che will continue to override UD in downstream every sprint release

Additional context

This issue is part of the #13265 epic

[akurinnoy]

@ibuziuk You are right, all this may and should be done in upstream for downstream projects to be able to configure UD just using their own product.json.

Controller Team can handle this issue.

[ibuziuk]

@akurinnoy this would be awesome. Have you planned anything from this list as part of the next sprint? We would be happy to give a hand on some parts

[amisevsk]

Ephemeral toggle on Create Workspace screen - https://github.com/redhat-developer/rh-che/tree/3579c2a1618d60980be0533a6d8680a268c5b305/assembly/fabric8-ide-dashboard-war/src/app/workspaces/create-workspace

Another option that would be great to have for hosted Che is "use ephemeral by default", since part of the downstream changes to add the toggle also sets workspaces to persistVolumes: false on creation.

[ibuziuk]

@skabashnyuk @sleshchenko since there was a discussion about the potential move of the dashboard and wsloader to separate repos it would be great to solve this issue first. Otherwise, it will much complicate the life for Hosted Che update process
cc: @gazarenkov

[skabashnyuk]

@ibuziuk I don't see relation at all. However, I fully support you. This task looks important.

[ibuziuk]

@skabashnyuk the relation is that refactoring of UD in the upstream will lead to refactoring of the UD usage in Hosted Che (smth. that would be really great to avoid)

[skabashnyuk]

@ibuziuk I'm sorry I didn't know about any planned UD refactoring.

[akurinnoy]

My proposal on how to extend product.json in order to make the UD more configurable:

{
  // all existing fields are above

  // will add FAQ link to the footer
  "faq": "https://github.com/redhat-developer/rh-che/blob/master/FAQ.adoc",

  "configuration": {
    "menu": {
      "disabled": [
         // will hide specified sidebar menu items, disable corresponding routes 
         // and related functionality such as workspace sharing
         "organizations"
      ]
    },
    "misc": {
      "idePrefetch": [
        // resources to prefetch
      ]
    }
  }
}

I hope I missed nothing but if you have any suggestion please let me know.

[gazarenkov]

@akurinnoy what about Ephemeral toggle?

[akurinnoy]

@gazarenkov yes, I didn’t mention the ephemeral toggle because of this PR. Che Server already has default configurable value for ephemeral mode and it makes sense for User Dashboard just to consume it. So, in scope of this issue we only need to fetch default value for ephemeral mode and add another ephemeral toggle to Create Workspace page.

[sleshchenko]

@akurinnoy @olexii4 Just to left the result of our discussion here. We agree that we could introduce a more general format for a configuration that later can be extended and gives an ability for example to define navbar elements order or title, etc. For example:

---
configuration:
  views:
    organizations:
      navbar:
        displayed: true
        title: ''
        priority: 1
      enabled: 'true'
      baseRoute: "#teams"
    workspaces:
      views:
        sharing:
          enabled: 'false'
  footer:
    faq:
      title: ''FAQ"
      href/reference: ''che-7/docs/FAQ"
    docs:
      title: "Docs"
      href/reference: /che-7/docs

But it would require even more analysis and work on Dashboard side. So, the proposed format

{
  "configuration": {
    "menu": {
      "disabled": []
    },
    "misc": {
      "idePrefetch": []
     }
  }
}

is good enough to start and later we'll be able to provide a backward-compatible scenario to migrate to a new format if we'll see that it's needed.