Feature #3114

[Workbench] Add a "copy this collection to a project" button to collections page

Added by Peter Amstutz over 5 years ago. Updated about 5 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Phil Hodgson
Category:
Workbench
Target version:
Start date:
08/05/2014
Due date:
% Done:

100%

Estimated time:
(Total: 1.00 h)
Story points:
0.5

Subtasks

Task #3476: Add button and make it workResolvedPhil Hodgson

Task #3484: Review 3114ResolvedPhil Hodgson

Associated revisions

Revision 36c36077 (diff)
Added by Phil Hodgson about 5 years ago

Addition of button that copies the current collection to a specified project (refs #3114, #3476)
Not positioned anywhere yet: I just slapped it onto the top of the page.

Revision 4eae6236 (diff)
Added by Phil Hodgson about 5 years ago

Make Collection page's Copy into project use the standard chooser (refs #3114, refs #3476)
Also bug fix: now creates a copy of the link rather than the collection.
Also moved to the tab_line_buttons panel.

Revision 6b0ad588
Added by Tom Clegg about 5 years ago

Merge branch '3114-copy-to-project' closes #3114

History

#1 Updated by Tom Clegg over 5 years ago

  • Subject changed from Add a "copy this collection to a folder" button to collections page to [Workbench] Add a "copy this collection to a project" button to collections page

#2 Updated by Tom Clegg over 5 years ago

  • Target version set to 2014-08-06 Sprint

#3 Updated by Tom Clegg over 5 years ago

  • Category set to Workbench

#4 Updated by Tom Clegg over 5 years ago

  • Story points set to 0.5

#5 Updated by Tom Clegg over 5 years ago

  • Assigned To set to Phil Hodgson

#6 Updated by Tom Clegg over 5 years ago

  • Target version changed from 2014-08-06 Sprint to Arvados Future Sprints

#7 Updated by Radhika Chippada about 5 years ago

  • Target version changed from Arvados Future Sprints to 2014-08-27 Sprint

#8 Updated by Phil Hodgson about 5 years ago

  • Status changed from New to In Progress

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?

#9 Updated by Phil Hodgson about 5 years ago

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).

#10 Updated by Tom Clegg about 5 years ago

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").

Two suggestions about UI presentation:
  • 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.)

#11 Updated by Phil Hodgson about 5 years ago

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?

#12 Updated by Tom Clegg about 5 years ago

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.)

#13 Updated by Phil Hodgson about 5 years ago

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?

#14 Updated by Tom Clegg about 5 years ago

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
This does something weird that I couldn't quite get to the bottom of:
  • 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

#15 Updated by Phil Hodgson about 5 years ago

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.

#16 Updated by Tom Clegg about 5 years ago

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!

#17 Updated by Anonymous about 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Applied in changeset arvados|commit:6b0ad588b44ee30cd400e85031b56dcb2a8ac567.

Also available in: Atom PDF