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
Bug 1830181: Hide 'Start Last Run' button on topology overview page when no PLR present #5258
Conversation
/retitle Bug 1830181: Hide 'Start Last Run' button on topology overview page when no PLR present |
@vikram-raj: This pull request references Bugzilla bug 1830181, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A change of the current UX needs to be run by @openshift/team-devconsole-ux @vikram-raj Please make sure you tag them when doing so.
With that said, I'm personally not in the favour of hiding the button. My stance on when to hide and when to disable a button is around "can the user find use in seeing a disabled button". I think in this case there isn't a lot, but there is some.
The user can head over to the Pipelines page (clicking on the Pipeline name/link provided) to start the Pipeline for the first time. This allows them to fix the disabled button. With no button, it breaks the current view expectations on "some are startable - they have buttons; some are not startable - they do not have buttons". Take Pods for instance, how do we know there is not supposed to be a button there and the user just needs to do one thing before making that happen?
To close off my rant 😄 I think our solution here is actually to show a disabled button if the current user permissions allow them to access that resource. So your 'consoledeveloper' (and 'kube:admin') user would see a disabled button even if there was not a Pipeline Run yet.
@openshift/team-devconsole-ux Please feel free to override what I just said if you'd prefer the button always hidden when it's disabled.
isAllowed && ( | ||
<Button variant="secondary" onClick={callback} isDisabled={pipelineRuns.length === 0}> | ||
isAllowed && | ||
pipelineRuns.length && ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please avoid doing array.length &&
logic @vikram-raj - it is currently rendering 0
when it's false.
@@ -23,8 +23,9 @@ const TriggerLastRunButton: React.FC<TriggerLastRunButtonProps> = ({ | |||
const { label, callback, accessReview } = rerunPipelineAndStay(PipelineModel, latestRun); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you also change this to PipelineRunModel
I missed it in my original review of this code. We are not passing a Pipeline, but a Pipeline Run.
@andrewballantyne Currently, we are hiding all actions on the overview panel if the user has no access to edit. |
If the user has no access to do any action no matter the state of things, then that's by design. They lack the permissions to do the action, and no matter the state of the app, their permissions do not grant them access to buttons / actions. If you start hiding buttons that are not disabled because of permission reasons, you are giving the wrong impression imo. The user should see the disabled button if they are an Admin or a user with 'edit' access. Because the state of the app can change and present the button for use to that user. Naturally all the above is conditional on their permissions not changing. Please make sure UX provides feedback on this @vikram-raj |
@vikram-raj Thanks for looping me in. I agree with @andrewballantyne that we should disable the button for the developer view instead of removing for the admin/developer view. If this was never an option (permission related) I think your solution would be correct. The disabled button gives them a cue that there is something they can do. I would ask @serenamarie125 to weigh in as well. |
@vikram-raj: This pull request references Bugzilla bug 1830181, which is valid. 3 validation(s) were run on this bug
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@andrewballantyne @beaumorley I updated the PR and screenshots PTAL. |
<Button | ||
variant="secondary" | ||
onClick={callback} | ||
isDisabled={!isAllowed || pipelineRuns.length === 0} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will show the button for View-only users. This breaks the first criteria of the sidebar.
If the user has no access to do any action no matter the state of things, then that's by design. They lack the permissions to do the action, and no matter the state of the app, their permissions do not grant them access to buttons / actions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This solution aligns better with the desired UX. Just a couple minor changes left I think.
impersonate?; | ||
}; | ||
|
||
const TriggerLastRunButton: React.FC<TriggerLastRunButtonProps> = ({ | ||
pipelineRuns, | ||
namespace, | ||
impersonate, | ||
}) => { | ||
const latestRun = usePipelineRunWithUserLabel( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While debugging the solution... I noticed a bug I accidentally made, can correct at the same time here?
In pipelineruns/triggered-by/hooks.ts:
// Today
return mergeLabelsWithResource(labels, plr);
// Suggested Change
return plr && mergeLabelsWithResource(labels, plr);
That way it doesn't merge a label onto nothing creating an invalid k8s object.
const { label, callback, accessReview } = rerunPipelineAndStay(PipelineModel, latestRun); | ||
const { label, callback } = rerunPipelineAndStay(PipelineRunModel, latestRun); | ||
const accessReview: AccessReviewResourceAttributes = { | ||
group: PipelineRunModel.apiGroup, | ||
resource: PipelineRunModel.plural, | ||
namespace, | ||
verb: 'create', | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure we want to toss out the accessReview
that the utility provides... perhaps we do this:
const { label, callback, accessReview: utilityAccessReview } = rerunPipelineAndStay(PipelineRunModel, latestRun);
const defaultAccessReview: AccessReviewResourceAttributes = {
group: PipelineRunModel.apiGroup,
resource: PipelineRunModel.plural,
namespace,
verb: 'create',
};
const accessReview = _.isEmpty(utilityAccessReview) ? defaultAccessReview : utilityAccessReview;
resource: PipelineRunModel.plural, | ||
namespace, | ||
verb: 'create', | ||
}; | ||
const isAllowed = useAccessReview(accessReview, impersonate); | ||
return ( | ||
isAllowed && ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you also change the button logic to be more deterministic?
<Button variant="secondary" onClick={callback} isDisabled={pipelineRuns.length === 0 && !callback}>
Making sure we have a callback to use before enabling the button will help if there is ever an issue with the callback, we don't have a button enabled without a callback.
EDIT: Updated the logic, thanks for catching the mistake
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
- "consoledeveloper" does not see any button when only having View access
- "consoledeveloper" see a disabled button when having Edit access and no Pipeline Runs
- "consoledeveloper" see an enabled button when having Edit access and having at least 1 Pipeline Run
- Admin is unaffected
/retest |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: andrewballantyne, vikram-raj The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest Please review the full test history for this PR and help us cut down flakes. |
@vikram-raj: All pull requests linked via external trackers have merged: openshift/console#5258. Bugzilla bug 1830181 has been moved to the MODIFIED state. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Fixes:
https://issues.redhat.com/browse/ODC-2403
Analysis / Root cause:
When viewing the Pipeline Runs in the overview sidebar of topology, the consoledeveloper doesn't see the button when there are no pipeline runs, but does as soon as there are.
Solution Description:
Hide 'Start Last Run' button on topology overview page when no PLR present. For admin as well as for developer.
Screen shots / Gifs for design review:
Browser conformance: