Arvados

Also doesn't seem to give the copied collection a name. In any case, if I'm on the right track, I can continue down this path and presumably uncover how that works (calling it "Copy of collection name" as with Add Data on Projects page).

Phil Hodgson wrote:

I have deactivated the "new project" button that the user might expect to see in the Project selector dropdown. Do we want to implement this?

That would be nice but I think we should set it aside for now unless it's trivial to implement.

Also doesn't seem to give the copied collection a name. In any case, if I'm on the right track, I can continue down this path and presumably uncover how that works (calling it "Copy of collection name" as with Add Data on Projects page).

Yes, please do. When viewing a named collection in workbench, the URI has the UUID of a name link, and that's what should be copied. (The UI should still say "copy collection" but under the hood it's really just "copy a name link" or "create a new name link").

• Using a blue button and a dialog box chooser like the "Move project..." button would be more consistent, and should be approximately as quick to implement using the generic chooser code. (Presumably we'll want a "create new project" button in that dialog at some point anyway.)
• Moving the button to "tab_line_buttons" would also be more consistent. (Aside: The three panels at the top of the collections page need some pretty serious reinventing.)

Okay, I've implemented it as you've described. Two questions:

• Is it normal that the action button on the chooser is enabled even when nothing has been selected yet?

• I've opted for the option that redirects to the project you copied to. Is it normal that if you choose the "root" project ("Home") that it shows the metadata page for that project rather than the normal "show" page?

Phil Hodgson wrote:

Okay, I've implemented it as you've described.

Looks great

• Is it normal that the action button on the chooser is enabled even when nothing has been selected yet?

Hm, it appears " data-enable-if-selection disabled" attributes need to be added in views/projects/_choose.html.erb. Unfortunately there's a fair bit of copy-and-paste between that and application/_choose.html.erb as it stands. It would be great to DRY that up. Up to you whether you want to tackle it now.

• I've opted for the option that redirects to the project you copied to. Is it normal that if you choose the "root" project ("Home") that it shows the metadata page for that project rather than the normal "show" page?

That sounds undesirable. It's a consequence of the "home" project being represented as thing.owner_uuid current_user.uuid rather than the uuid of a Group object.

I think it would be acceptable to deal with this by redirecting users#show to projects#show if uuidcurrent_user.uuid. (I don't think there's any other known use for users#show. Theoretically an admin could want to look at the user's "generic attributes" page, but a nicer version of that would be to fix projects#show so it works for any user's home page, subject to whatever permissions you have via admin or any other mechanism.)

Just committed to 3114 branch:

• copied the data-enable-if-selection disabled attributes so that something must be selected before the button is enabled

• redirected users#show to projects#show if uuid==current_user.uuid

For the other two requests (DRYing up the choosers, and the business about handling projects#show to handle any user's home page) let's make new stories perhaps?

Phil Hodgson wrote:

• copied the data-enable-if-selection disabled attributes so that something must be selected before the button is enabled

Looks good, thanks

• redirected users#show to projects#show if uuid==current_user.uuid

• Click "copy to project..."
• Choose "My Projects" (aside: we should rename this to Home now that it's usable as a project)
• Click OK
• POST /actions as JSON → redirect to /users/{userid}
• GET /users/{userid} as JSON → redirect to /projects/{userid}
• GET /projects/{userid} as JSON → 200 OK (but chrome refuses to show me this response content!)
• GET /users as HTML → the generic users#index page.

Seems like coercing things back to HTML somewhere in there will be part of the solution. But first of all, can you reproduce this? Or should I be looking for something that's gone subtly wrong in my environment?

For the other two requests (DRYing up the choosers, and the business about handling projects#show to handle any user's home page) let's make new stories perhaps?

Good plan

Indeed, a strange little bug, which I think I fixed in my last commit to this branch. In fact it is javascript that is doing the coercion, forcefully setting the browser location after successful AJAX using a specially set href attribute in the JSON response. This href attribute was coming from a call to url_for in ApplicationController#show which it seems to me could not ever have worked properly, but I'm not 100% sure: I like to be much more explicit in my calls for routes. My uncertainty comes from not knowing what other purposes a JSON request to ApplicationController#show is meant to serve.

According to my reading of git log -p and git log --graph, ec56622 introduced that href key in order to make x-editable behave correctly when the act of editing brings a new object into existence. I think an example of this is editing the name of a previously unnamed object whose type doesn't have a "name" field -- this involves creating a new name link. (Incidentally it looks like this "name link" stuff may go away entirely in #3036, which could make this behavior irrelevant.)

There's an integration test in 'projects' called 'Add a new name, then edit it, without creating a duplicate' which looks like it should test this. Since that test passes, I'd say this change doesn't break anything.

For consistency/predictability we should probably update the similar url_for() in ApplicationController#create. Other than that, LGTM/merge, thanks!