Uploaded image for project: 'Red Hat Internal Developer Platform'
  1. Red Hat Internal Developer Platform
  2. RHIDP-8197

Extensions plugin: Install and configure plugins - 1.8 - Align installed plugins tab with UX design by replacing the internal installed plugin

    • M
    • False
    • Hide

      None

      Show
      None
    • False
    • 50% To Do, 50% In Progress, 0% Done

      Feature Overview (aka. Goal Summary)

      The Extensions plugin uses some workarounds to show the "Installed [Plugins]" tab from the internal "Dynamic Plugins Info plugin" and the "[Plugin] Catalog" itself.

      The expectation (design, pm, eng?) is that both are related and are delivered by the extensions plugin.

      Goals (aka. expected user outcomes)

      Remove and integrate the "Dynamic Plugins Info plugin" from rhdh and ship all extensions related code in the extensions plugin.

      Please note that the old "internal" plugin focused on packages and the designs for the installed tabs shows Plugins. It might be easier to reimplement the page.

      Question / TBD: How should we show packages WITHOUT a plugin? Which means, dynamic plugins which are installed without a catalog entity?

      Figma Design

      Requirements (aka. Acceptance Criteria):

      1. Remove https://github.com/redhat-developer/rhdh/tree/main/plugins/dynamic-plugins-info and https://github.com/redhat-developer/rhdh/tree/main/plugins/dynamic-plugins-info-backend and integrate the components and the backend (if possible) into the extensions plugin.
      2. Align the designs where possible with the Figma Design
        • Use icons for the tabs
        • Rename Installed to "Installed plugins"
        • Show installed plugins table.
        • Include packages that are part of any known plugins (double check with UX/PM)
      3. No CSV export from the UI
      4. Cleanup/Remove all internal.plugins/tab workarounds and the InstallationContextProvider from the extensions code base and simplify the code around the installed alert.
        • Might keep the Provider and replace it with a NullComponent to be backward compatible for 2 releases?

      Out of Scope (Optional)

      1. Any new feature like Reboot, Config Rollback, Automatic Rollout
      2. Mostly any other UX updates other then the Extensions > Installed tab page or small UX alignment
      3. To downsize this feature we don't want show this information that we don't have at the moment. For example:
        • Status "Installing..." because the plugins are always installed in the init container
        • Status "Failed" => we don't know this at the moment?! We could maybe have a spike if we know if a plugin is enabled but not available?!?!
        • "View logs..." link => we don't have access to that at the moment
        • Installed timestamp/admin username => we don't know that at the moment
        • Uninstall icon/button since we don't want to delete plugins from the dynamic-plugins-root folder for now. We can just enable/disable these plugins for now.
      4. Notifications plugin integration (notifications when a new plugin is available)

      Customer Considerations (Optional)

      Documentation Considerations

              dsantra12 Debsmita Santra
              cjerolim Christoph Jerolimov
              RHIDP - Frontend Plugins & UI
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: