As an end user I should be able to include my own endpoints.

[cyrano007]

As an end user I should be able to include my own endpoints.

As end user (no admin)
I want to be able to add my own endpoints,
so I can add my K8s test cluster or CF endpoints without asking the admin
and they are not visible to other users

[richard-cox]

This shouldn't be too bad too implement. Though need to consider

• feature should be off by default and enabled by admin at deploy time
• add endpoint button should be visible only if is admin or the flag is enabled
• need to consider features in endpoints that are normally disabled via admin not adding endpoint (more specifically kube/helm features in non-kube environments, artifact hub, etc)

[nwmac]

@richard-cox Its a little more complicated I think - at the moment endpoints are effectively shared - they exist for all users across the system - and are added by admins.

I think we'd need to the notion of system endpoints as well as user endpoints - need to ensure we handle the case where an endpoint has been added by a user and then the admin adds it at the system level - we'd have the same endpoint in twice - the user's endpoints should probably always take precendence.

[cyrano007]

Hi,
what does the Community Label mean for my request ?

[richard-cox]

Hi @cyrano007 , we track all our issues in github and tag those that come from outside the team with Community

[thquad]

Hello,

i would like to be assigned to this issue. What is the usual way of communication between developers (e.g. Slack)? As is stated in the docs, i would like to get in touch with the developers first to discuss my approach.

[richard-cox]

From slack

https://cloudfoundry.slack.com/archives/C80EP4Y57/p1610704654001800

Now i’m at a point where i’m implementing the logic for differentiating between user-endpoints and admin-endpoints. Since n users can create m endpoints, i thought about creating a junction table between endpoints and the respective creators of endpoints. But i think the cleanest approach would be to add a new column in the cnsi table, for the user-id who created the endpoint. If the same endpoint would be created twice, two records would be added to the table with a different user. This would prevent that configurations of one endpoint between users would affect all users.
Things to consider:

    All users should see all admin-endpoints.
    Endpoint-admins see their own endpoints too.
    Endpoint-admins should not be able to edit admin-endpoints. (same rights as current users have)
    Admins should see all endpoints and be able to edit them.
    For all endpoints which already exist before the code changes, records without a saved creator are considered to be created by an anonymous admin for backwards compatibility.

...

I think the approach generally looks ok. Below are some additional points to consider

• Frontend. At the moment the frontend handles endpoint state quite simply as admin (can register) and user (cannot register). This introduces a third state of user (can register). This will need to be taken into account when..
  • Behaviour when there are no endpoints. At the moment this is...
    • user logs in ... see's a custom screen and they can't do anything or navigate anywhere (it's a dead-end)
    • admin logs in ... redirected to endpoints page and custom text shown on page
  • Showing the add endpoint button '+'
  • Showing the edit action in the endpoint drop down
  • Showing the unregister action in the endpoint drop down
  • When registering an endpoint we show the option to 'share' it with other users. user specific endpoints should not be shared. this should be hidden if user is not an admin
  • Need to display some kind of indication that an endpoint is personal or global in the endpoints list.
• Need to consider how admins manage user specific endpoints. How are these endpoints added to the endpoints table... should they be kept separate? If included in the endpoints table, and any request of the admin to list endpoints, how are they stopped from using that endpoint themselves?
• Config
  • This should be disabled by default via env var. We handle these via config.properties/config.examples/etc and ./jetstream/repository/interfaces/structs.go PortalConfig
• DB
  • Heads up, any changes to the db need to be done via ./src/jetstream/datastore
  • when adding an endpoint the url must be unique (the cnsi guid is a kind of hash of the url). So would need to handle situations where the admin adds an endpoint with the same url that a user has
• Docs
  • Some initial docs on how this is configured and what it does should be added to somewhere in the /website docs