Move shortcut settings from user/%user/shortcuts to user/%user/edit

I'm not sure that this is a critical issue ... but I agree that the user shortcut settings should be moved. This patch does exactly that...

Here testbot ... here boy

I had a small error in my original patch ("edit" links were not working properly next to the shortcut set names) ... this patch fixes it

Blaaarg! Whitespace (I swear I'm getting better about this)

adding tag so it shows up in usability queue (not sure why #d7ux didn't do the trick)

Subscribing. It does seem to make sense to at least make it a tab.

I haven't looked too carefully at the patch, but there's a bit of a tricky issue here - for site administrators, they need to sometimes be able to view shortcut sets outside of the context of an individual user account, whereas for non-site-administrators, they need to be able to have a clear place that they get redirected to (within their user account) to when they click the "edit shortcuts" link in the toolbar.

Also, to the extent that an overall strategy for the UI is being discussed at #680500: Shortcuts violate Drupal UI standards, that issue is probably relevant for this one.

Just as a note: The OpenID module also puts its form on the same level as the existing Shortcuts module. So if you are going to make this fix, it should apply to OpenID as well. Both are doing similar things (editing settings related to your acocunt).

That's true, and contrib modules put a lot of editable things up there too. It's not clear there's an overall standard. Basically, in the absence of a standard, it seems like only things that are supposed to be "visible" should be in the top level like that.

Probably neither shortcuts nor OpenID need to be particularly visible, so could be underneath the edit page, as its own tab.

clearly this isnt happening in D7

From my point of view this is the correct decision, we want to core adhere to this standard. If we can get a code review on this its RTBC from me.

What is strange, is that we are moving something which was a page, to something that is just a form. We will need to increase the usability of this thing if we want to do that.

This is not a bug at all nothing is broken, it is a task so I moved it to 8.2.x. This is pure usability issue and we need wire frame to start working on this so I changed the status to active.

FWIW, this change would solve a usability problem the owners are having with a site I just launched for them.

They mostly have a 1:1 mapping of roles to shortcut sets (so #1122816: Assign shortcut set to role would be a win), but not always (I hope #1122816 will allow overrides and simply defines an initial default set). When they create new accounts, they can assign a role on the account form, but they have to wait until the user account exists, remember to click the rather easy-to-miss link to the new user's account page in the green success message (the /admin/people/create form redirects to itself on success, not the new user's account page), then find the shortcuts tab, then wait for a new page to load, and finally select the right shortcut set for the user they just created. There's also a race condition if the new user logs in before the admin does all this, and sees a default set, not the intended set for their account. Worse, if you change the shortcut set for a currently logged-in user, it appears you need to do a full cache

It'd be much better for them to be able to select the shortcut set directly on the account creation form, which I believe this issue would enable.

Thanks,
-Derek

This change will be implicitly done when the shortcut set user assignment has been moved from the current DB table to a regular user entity field.