XMLWordPrintable

    • Permissions check NPM
    • Product / Portfolio Work
    • False
    • Hide

      None

      Show
      None
    • False
    • Unset
    • To Do
    • CRCPLAN-311 - Management Fabric | M4 - User Access Administration via Access Management and Workspaces
    • 100% To Do, 0% In Progress, 0% Done

      Review the CRCPLAN parent feature for additional context, including the feature overview, goals, user stories and use cases, acceptance criteria, designs, dependencies, risks, assumptions, pending questions and documentation callouts.

      Summary and goal

      This epic aims to integrate the new Kessel access check service into our application. This service will be exposed as a REST API that takes a Workspace ID (WS ID) and a permission name, returning a boolean value (true or false) indicating whether the user has the specified permission for that workspace. The end goal is to provide a standardized and reusable NPM package that any frontend or backend application can use to perform these access checks, with the flexibility to configure the API URL and basename. This will enable granular access control for new V2 Workspace and V2 Rolebinding APIs, using new permissions such as `inventory_group_view` and `inventory_group_update`.

      Acceptance Criteria 

       

      These conditions must be met for the epic to be considered complete. This provides a detailed definition of scope and the expected outcomes, written from a user's point of view.

      1. The team has created a new NPM package for Kessel access checks.
      2. The NPM package can be installed and used in any JavaScript/TypeScript project.
      3. The package exposes a function that accepts `wsId` and `permissionName` as parameters.
      4. The function sends a request to the Kessel REST API endpoint `/kesselcheckservice_check` with the provided parameters.
      5. The function returns a promise that resolves to a boolean value (`true` or `false`) based on the API response.
      6. The package allows for configuration of the base URL and basename of the Kessel API endpoint.
      7. Documentation is provided for the NPM package, including installation instructions, usage examples, and configuration options.
      8. Unit tests are created for the NPM package to ensure its functionality and reliability.
      9. The package handles potential API errors (e.g., network errors, 404, 500) gracefully and provides a clear error response.
      10. The package is published to the internal or public NPM registry.

      Checklist

      Checklist Item Required Notes or Comments
      Workstream or external team dependencies? Y Dependency on the Kessel team to provide the REST API endpoint and ensure its stability and availability.
      ADR Required? 
       * Long-form (approval)
       * Short-form (informational)
      Y Short-form ADR required to document the decision to create a separate NPM package for this functionality and to outline the package's design and architecture KSL template
      Testing plans
       * New automation or update existing?
      Y New automation is required for the NPM package. This will include unit tests and possibly integration tests against a mock API.
      Known dependencies? 
       * Link to the dependent Jiras
       * Add details
      Y
      • Dependent on the completion of the Kessel API endpoint (link to relevant Jira ticket).
      • Dependencies on any necessary authentication or authorization mechanisms required by the Kessel API.

      Open Questions

       

      Capture any open questions and resolutions related to the epic goal or acceptance criteria. Add any additional details, questions or decisions that need to be made or addressed. 

      • What is the exact API endpoint URL and basename? Is it configurable per environment (dev, staging, prod)?
      • What authentication method will the API require? (e.g., API key, OAuth token, etc.)?
      • How will the NPM package handle token management or authentication? Will it be a responsibility of the consuming application to provide the token, or will the package handle it?
      • What is the expected response format for errors from the API?
      • Should the NPM package include TypeScript typings out of the box?

              bflorkie@redhat.com Bryan Florkiewicz
              khala-1 Karel Hala
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: