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

Improvement: change the order of items in the context menu #88

Closed
bobted opened this Issue May 21, 2018 · 11 comments

Comments

2 participants
@bobted
Copy link

bobted commented May 21, 2018

When using Jenkins View for a multibranch pipeline, the Remove context menu item is available for each branch within the job. If a branch is deleted using the menu item, it reappears during the next refresh of the Jenkins job.

Can this menu item be changed to ignore the selected branch? Either by removing from the list or to show it with a different icon which does not propagate to the overall status.

The root of the issue is a deleted branch which had a last build status of failed. The Jenkins job is setup to scan the repository for deleted branches, but we are retaining the build for 7 days after the branch is deleted. During those 7 days, the overall status shown by AnyStatus is "failed" due to the 1 branch that no longer exists.

@AlonAm

This comment has been minimized.

Copy link
Member

AlonAm commented May 24, 2018

What happens when you disable the deleted branch from the context menu and then refresh?
Is it still disabled?

Thank you for the feedback!

@AlonAm AlonAm changed the title Option to ignore a build in Jenkins View for multibranch pipeline Feature: ignore a build in Jenkins View for multibranch pipeline May 24, 2018

@AlonAm

This comment has been minimized.

Copy link
Member

AlonAm commented May 24, 2018

According to my test, if you disable one of the jobs in the view, it stays disabled (even if you restart). Does that solve the issue?

@bobted

This comment has been minimized.

Copy link

bobted commented May 24, 2018

The Disable seems to be what I was looking for. I think when I first saw the option to Disable, I assumed it meant I could disable the Jenkins job in Jenkins, not the status updating within AnyStatus.

But now that I know it is there, I would suggest a couple things with it: change the icon for Enable/Disable so they are different than the Start, and somehow differentiate options that execute something in CI compared to local application commands.

@AlonAm

This comment has been minimized.

Copy link
Member

AlonAm commented May 24, 2018

I agree with you. My first plan was to add a sub-menu called "Tasks" that shows the actions that are supported by the widget such as Open in Browser, Start, Stop, Restart, etc. Similar to the "All Tasks" menu in Windows Services Manager:
image
The reason I didn't add the sub-menu is because it adds another mouse-click for the user to execute the task, including Open in Browser, and I wasn't sure about that. What's your opinion about it?

@bobted

This comment has been minimized.

Copy link

bobted commented May 25, 2018

I'll admit that I'm terrible at UI/UX... Limiting the mouse clicks or simply keeping the required input to a minimum seems to be the right approach. My main concern or issue what not being able to discern what the Disable menu item meant, or rather what the scope of that command was.

Maybe it comes down to an additional work with each command. "Start" is "Queue Build" or "Disable" is "Disable Tracking" or something like that. Then you keep a single menu and minimal clicks; however you lose some cleanliness of the UI due to the extra words (if that's a concern).

@AlonAm

This comment has been minimized.

Copy link
Member

AlonAm commented May 25, 2018

Good points.
Do you prefer a flat menu with more text over a sub-menu? (IMO, more text is fine)
The Start, in the context of builds, was "Trigger a new build" in previous versions. I changed it because from the API perspective Start and Trigger is the same thing. Now "Start" is used for both builds and windows services (or anything that is startable).
I'll see if I can override the text for specific things like builds.

@bobted

This comment has been minimized.

Copy link

bobted commented May 25, 2018

I have no preference between a flat menu with more text vs sub-menus. If you're repeating the same commands but in different context, it maybe better to use sub-menus.

Just thinking in the context of something like reusing a view model for the sub-menus that only hold their menu items. Whenever a user clicks on "Start", the sub-menu calls back to it's parent that start was called. The parent menu item can either handle the event or raise it's own event with a actual command to fire: CI Build Start vs Start Tracking Build Status.

@AlonAm

This comment has been minimized.

Copy link
Member

AlonAm commented May 25, 2018

Here's an alternative layout proposal. In this layout the actions that are "remote" will be shown under "All Tasks" such as Start, Stop, Restart, Approve, etc. The "Open in Browser" option will be visible above "All Tasks" for easy access. Underneath, there's a group of "general" commands, such as disable, enable, copy, paste, etc.

image

image

I think the "All Tasks" sub-menu makes it obvious that this is a different type of a command.
And, the additional step of opening the sub-menu, makes you double-think before you click the Start button.
What do you think?

@bobted

This comment has been minimized.

Copy link

bobted commented May 26, 2018

I like it. It makes sense to me, both the group and your reasoning behind it.

I’d say go for it.

@AlonAm AlonAm changed the title Feature: ignore a build in Jenkins View for multibranch pipeline Improvement: change the order of items in the context menu May 27, 2018

@AlonAm AlonAm added this to the Release 2.1 milestone May 27, 2018

@AlonAm

This comment has been minimized.

Copy link
Member

AlonAm commented May 30, 2018

Released in 2.1.12
@bobted thank you for your feedback!

@AlonAm AlonAm closed this May 30, 2018

@bobted

This comment has been minimized.

Copy link

bobted commented May 31, 2018

Glad I could contribute. I installed 2.1.12 yesterday. Looks good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment