-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ability to disable links to resource details pages on a resource extension list page #3381
Comments
I took a quick look at it this morning and got something working relatively quickly, however it's incomplete and going to need some more thought. Due to the way routing and some API stuff currently works it's only possible to disable the links when navigating to the page from the left nav. This is then persisted for the duration of the browser session. However, if a user navigates directly to the page (e.g. via bookmark) the app is not aware that the page is related to an extension and does not know to apply special treatment. We're currently reworking some of this routing anyway as part of a set of major dependency updates so I'll see if the newer versions help here and post any relevant updates on this issue. |
For reference, these are the changes I was testing this morning: AlanGreene@3dea974 |
Confirmed that this functionality works as expected with the new routing approach, and correctly disables the links regardless of how the user navigates to the page. The implementation is quite different to the one linked above, I'll share details soon. We'll start work on delivering the required changes for the new routing approach after the upcoming LTS release and post updates as they're available. |
For my own reference: once #3465 and the follow-up PR to unify the resource containers are merged, this is the change that needs to be applied to support the |
The updates and refactoring mentioned above for #2452 and related issues which were blocking this took much longer than anticipated due to other commitments, but all blockers are now resolved. #3489 was merged today and is available in the latest nightly (read-only, read-write), it will also be included in this month's v0.49.0 release. To disable links to the resource details page from a resource extension list page, add @charlesmorin @palacerteupgrade fyi. Thanks again for the feature request and your patience. |
v0.49.0 LTS is available now with this feature: https://github.com/tektoncd/dashboard/releases/tag/v0.49.0 |
Feature request
Request from @charlesmorin, see https://tektoncd.slack.com/archives/CHTHGRQBC/p1712847670612199 (copied most relevant bits below):
is there a way in Tekton Dashboard to disable hyperlinks on list items when using a custom extension? I am trying to come up with only a list of custom items and would like to remove the hyperlink on each rows. Thank you
Use case
We built an external queue system for our Tekton platform (dynamodb+s3), which consists on a webhook interceptor on a event listener, a golang service that handles/ingests webhook and decides if a pipelinerun must be created out of a webhook. If the cluster is too busy, we queue the item (webhook). We have a golang worker that continuously monitors the cluster capacity and trigger pipelines when there’s room (firing off a webhook to another event listener which will trigger pipelineruns). Upon successful dispatch of a queued webhook, the worker pops the items out of the queue.
We want devs to see the current queue just like they have on Jenkins (what the repository is, the PR number, the priority in queue, etc), so we leveraged the custom extension to add a PipelineRuns Queue item in the sidebar. It’s not meant to ne sophisticated UI by any means. We just need a pretty simple list of queued items so people can see what’s pending in the queue. Each rows in the page has an hyperlink on it, which you can imagine gives a 404 since we’re not displaying a resource per se.
Let me know if you have ideas as for how I could have more control on the page layout, if that’s possible. Thanks Alan!
here’s what I got in my cluster:
then we leverage istio to proxy that specific endpoint so that our backend returns what we need in the format the dashboard expects.
Alternatives
Additional context
The text was updated successfully, but these errors were encountered: