Group-level new issue & MR using previously selected project

@ClemMakesApps Nope, it wasn't. I need to look into that. I'm pretty sure it occurred because I had to move the selectors on the buttons around a bit here.

Overall looks good, theres also a merge conflict apparently.

I haven't tested this locally, will do in the next review round

assigned to @brycepj

@ClemMakesApps I fixed everything you pointed out and resolved conflicts. Can you take another look?

assigned to @ClemMakesApps

added 481 commits

63c549e8...699a30f0 - 480 commits from branch master
ac44d605 - Cache recent projects for group-level new resource creation.

Compare with previous version

changed the description

@brycepj can you include changelog for this change?

1. The dropdown should be disabled when user is logged out

2. New issue button is disabled even though I am logged in

UX seems weird

3. Dropdown caret isn't centered

@brycepj can you correct the changes? @tauriedavis after that can you review the UX?

assigned to @brycepj

The dropdown should be disabled when user is logged out

@ClemMakesApps I left it this way (Flash error on project dropdown) because it's the current behavior for these buttons. But if that's a UX change we want to make, I can do that.

New issue button is disabled even though I am logged in

This is intended. You can't create a new issue until you've selected a project. @victorwu looked at this with me and gave the . I'm open to other approaches though -- I just didn't really see a better one.

Dropdown caret isn't centered

Nice catch. I didn't see that. I'll fix it.

(2) still seems kind of buggy to me. wdyt @tauriedavis?

> @brycepj can you include changelog for this change?

Done: bb8800d

I left it this way (Flash error on project dropdown) because it's the current behavior for these buttons. But if that's a UX change we want to make, I can do that.

Yes, the current behavior is strange. It should allow the user to select the project and then be taken to the log in screen. After logging in, the user should be taken to the create issue page for that project. This is how it works when trying to create an issue from an individual project.

New issue button is disabled even though I am logged in

This is pretty strange. I don't really understand the decision behind making this into a split dropdown button.

Usually our split drop downs are used to select different actions that the button can perform. Examples:

Comment OR Start discussion
Create a merge request OR Create a branch
Close issue OR Report abuse

This button is only one action: creating a new issue. So it is strange to select the project from the right and the have to click New issue after. How is this an improvement from the current button where you only have to select once? Do we have any split buttons where the action remains the same? Maybe @sarrahvesselov has some insight since she commented on the issue originally. Is this the best solution to the problem?

To throw out one alternative: One option would be to not include a dropdown on this button at all. Allow the user to click New issue and go to the new issue page. Add a required project select dropdown on the issue page itself instead.

I see the dropdown twice and some weirdness when resizing:

I'm not sure exactly why we require a user to be logged in to request the list of projects in a group (in a dropdown), but you can visit the groups dashboard and see all the projects in the group without being logged in. Maybe @smcgivern can comment on this?

This button is only one action: creating a new issue. So it is strange to select the project from the right and the have to click New issue after. How is this an improvement from the current button where you only have to select once? Do we have any split buttons where the action remains the same?

@tauriedavis The motivation was primarily to show a default project (based on projects previously selected) without having to re-select from the dropdown. In that case, we can't make a single button responsible for triggering a dropdown (if the default is not the one you want) and navigating to a new issue.

I don't think adding a button selector to the new issue page would be a desired improvement, since the goal is to avoid requiring selection if possible. More importantly, the URL for the 'new issue' page is project-specific, so we can't send the user to it until they've selected a project.

It's also worth noting that after the first issue is created, the user will never see the button disabled again. There will always be a default displayed that allows them to click.

I see the dropdown twice and some weirdness when resizing:

That looks to be something related to the new nav. Nice catch. I'll look into it.

The motivation was primarily to show a default project (based on projects previously selected) without having to re-select from the dropdown. In that case, we can't make a single button responsible for triggering a dropdown (if the default is not the one you want) and navigating to a new issue.

I don't think adding a button selector to the new issue page would be a desired improvement, since the goal is to avoid requiring selection if possible. More importantly, the URL for the 'new issue' page is project-specific, so we can't send the user to it until they've selected a project.

It's also worth noting that after the first issue is created, the user will never see the button disabled again. There will always be a default displayed that allows them to click.

I'm not 100% convinced that showing a default is going to be clear to the user. It doesn't seem super intuitive to me. Nonetheless, if we do keep it as is in this MR, perhaps we can change the disabled New issue button to Select project to create issue

In particular, the whole point of the design is that users will have a default project to simply go to the new issue page with one click. That's most important and the net improvement. Other details we can iterate on later.

For the original state when there's nothing selected, I agree with @tauriedavis (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13058#note_36201376), simply better messaging could solve it. @brycepj : Could we simply replace the text to be Select project and create issue.

Regarding logged out behavior, what @tauriedavis describes (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13058#note_36199736), is parity with the new issue button on the project issue list page. @brycepj : I think we should do that. But I'm fine with pushing that to a later issue if that's a lot more work. (The use cases we care about primarily are logged in users.)

Sorry @brycepj . Just re-read all the communications again. Why does this apply to the group milestone page? On the latest group milestone list page, you can only create a group milestone from that page. So that doesn't apply right?

@victorwu you're right -- group milestones aren't tied to projects any longer, so this wouldn't apply. I've updated the description/title accordingly.

changed title from Group-level new issue, MR & milestone using previously selected project to Group-level new issue & MR using previously selected project

changed the description

Could we simply replace the text to be Select project and create issue

@victorwu I agree, that would be better. I'll do it.

I think we should do that. But I'm fine with pushing that to a later issue if that's a lot more work. (The use cases we care about primarily are logged in users.)

I think I could do this pretty easily. I'll get it into this MR.

I'm not sure exactly why we require a user to be logged in to request the list of projects in a group (in a dropdown), but you can visit the groups dashboard and see all the projects in the group without being logged in. Maybe @smcgivern can comment on this?

@brycepj I don't think this is the reason, but you can't necessarily see all the projects in a group while logged out (or even while logged in) - it depends on your access to those projects!

If we really want, we could make this API return public projects only when you're logged out - @rymai wdyt?

@victorwu @tauriedavis

When there's no default in local storage, this is what the user will see:

WDYT?

Small nitpick but shouldn't it be:

Select project to create issue

Since you select the project and then you create the issue? It's not happening at once.

@tauriedavis I had the same thought

Done: b2c53cd

resolved all discussions

@ClemMakesApps I think I've addressed all of your feedback, and I made UX revisions per feedback from @tauriedavis and @victorwu. Can you take another look?

assigned to @ClemMakesApps

@tauriedavis if the UX looks good, can you approve it?

added 100 commits

3e155936...725dae25 - 91 commits from branch master
0a4b6617 - Cache recent projects for group-level new resource creation.
f3a2757b - Add changelog.
f5da6c59 - Give more descriptive label when no default available.
9753c5a7 - Change button text to 'Select project to create {item}'
57456512 - Select select2 closest to click target.
2663618c - Update specs for new button label and separate fixture.
6f07e370 - Center down caret.
78ce7df7 - Update specs for new MR button.
68f551dc - Update spec to click nav link before url change.

Compare with previous version

added Deliverable label

~~I am still seeing the issue with multiple dropdowns using the new nav https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13058#note_36200104~~

Just kidding, I somehow wasnt up to date after pulling.

assigned to @brycepj

assigned to @ClemMakesApps

@ClemMakesApps it looks as intended in the issue description.

assigned to @brycepj

Oh I see!

assigned to @ClemMakesApps

From a UX perspective, shouldn't this dropdown be a select dropdown? The ones with the checkmarks?

This wasn't specified in the original description so Im not sure if its intended or I should I make a new issue.

On mobile views, the dropdown button is separated and I only see a loading icon for the button text

assigned to @brycepj

From a UX perspective, shouldn't this dropdown be a select dropdown? The ones with the checkmarks?

@tauriedavis yeah, I think so. But upgrading the dropdown implementation here would require a fair amount of refactoring, so we decided to do it separately.

On mobile views, the dropdown button is separated and I only see a loading icon for the button text

Ugh. Let me look at that again.

But upgrading the dropdown implementation here would require a fair amount of refactoring, so we decided to do it separately.

Is there an issue to do it separately yet?

@tauriedavis It was discussed in the main issue (https://gitlab.com/gitlab-org/gitlab-ce/issues/34411) and if/when https://gitlab.com/gitlab-org/gitlab-ce/issues/35735 happens, the dropdown upgrade would get done.

But I'm not sure whether they should be lumped together. Might be a question for @victorwu.

I think it's okay to leave it as select2 for now. We should just make sure we resolve that mobile view bug.

Yes @brycepj. Let's do #35735 (moved) as a separate issue.

Yep agree that only thing remaining here is the mobile bug from a user-facing prospective.

mentioned in issue #35735 (moved)

@ClemMakesApps For changes I needed to make to fix the issue with small screens, it made sense to use jquery in ProjectSelectComboButton. I can go in to detail on why, but tldr: we need to apply changes to multiple elements with a single selection, and native methods don't do that very nicely. We ended up saving a lot of space and complexity with it. Given that select2 is dependent on Jquery, we're not really introducing a new dependency here anyway.

Fair enough. Go for it!

resolved all discussions

@ClemMakesApps We're and I believe I've resolved all concerns.

assigned to @ClemMakesApps

I for some reason cannot run this locally anymore, @brycepj can you rebase?

assigned to @brycepj

I messed up something on my branch, that's why. Reassigning to me as I test this out locally

assigned to @ClemMakesApps

This is what I'm seeing on mobile viewport, should the select project to create issue stretch to full width on mobile viewport? @tauriedavis

Also, when the project name is really long and I reduce the viewport width size, this is what I get:

Should we truncate the name of the project when it gets too long so that the button stays grouped?

assigned to @brycepj

This is what I'm seeing on mobile viewport, should the select project to create issue stretch to full width on mobile viewport?

@ClemMakesApps I came across a couple examples where we do it the way it is now, but I see here that we do it the way you're imagining. It's definitely better, just requires some extra styles. I'll do it.

Should we truncate the name of the project when it gets too long so that the button stays grouped?

I don't think we do a very good job of truncating long project names most other places (e.g. Screen_Shot_2017-08-07_at_9.06.31_AM, but yeah, I don't think it would hurt. Will do.

That is an awesome screenshot for testing the limits. @sarrahvesselov you should check it out

@ClemMakesApps Truncation done: 80d540e

@brycepj

Should that be full width?

@ClemMakesApps Yeah, I haven't done that part yet. Although, this makes me think I should handle the truncating with CSS rather than JS. Because there's really no way to fill the space and accommodate different screen sizes otherwise.

@tauriedavis @ClemMakesApps How's this look? http://imgur.com/a/VT7mQ

resolved all discussions

assigned to @ClemMakesApps

added 406 commits

aacc9ae2...bfac6ce6 - 405 commits from branch master
e8be7134 - Cache recent projects for group-level new resource creation.

Compare with previous version

Checked out locally and LGTM

resolved all discussions

LGTM, Thanks @brycepj

approved this merge request

merged

mentioned in commit 184889cc

Merged! Thanks @tauriedavis, @victorwu and @ClemMakesApps for the all the good feedback and catching my silly mistakes!

resolved all discussions

mentioned in issue #36298 (closed)

If we really want, we could make this API return public projects only when you're logged out - @rymai wdyt?

Definitely!

mentioned in issue #37179 (closed)

Group-level new issue & MR using previously selected project

What does this MR do?

What are the relevant issue numbers?

Activity

1. The dropdown should be disabled when user is logged out

2. New issue button is disabled even though I am logged in

3. Dropdown caret isn't centered

Admin message

Admin message

Group-level new issue & MR using previously selected project

What does this MR do?

What are the relevant issue numbers?

Merge request reports

Activity

1. The dropdown should be disabled when user is logged out

2. New issue button is disabled even though I am logged in

3. Dropdown caret isn't centered