Idea #9426
closed
[Workbench] Display/Add/Edit/Delete tags on collection front page
Description
They should be displayed on the collection's front page, so they're easy to see at a glance. TBD: in the top section, or in the first tab?
Features to consider: a quick AJAX interface to add tags; a quick AJAX interface to remove tags (only accessible when the tag is writable by the current user).
Files
Related issues
Updated by Tom Morris almost 7 years ago
- Subject changed from [Workbench] Display tags on collection front page to [Workbench] Display/Add/Edit/Delete tags on collection front page
- Assigned To set to Radhika Chippada
- Target version set to 2017-06-21 sprint
Updated by Radhika Chippada almost 7 years ago
- File collection_tags_tab.jpg added
UI mockup of "Tags" collection tab.
Updated by Radhika Chippada almost 7 years ago
- File deleted (
collection_tags_tab.jpg)
Updated by Radhika Chippada almost 7 years ago
- File tags-tab-with-checkboxes-mockup.jpg tags-tab-with-checkboxes-mockup.jpg added
- File tags-tab-with-editable-table-mockup.png tags-tab-with-editable-table-mockup.png added
Added one more idea.
tags-tab-with-checkboxes-mockup (earlier mockup renamed): Here each tag is editable separately using pencil icons and checkboxes and trash icon etc. Each single edit (key or value or addition of a tag or deletion of a tag) is saved separately making an API call.
tags-tab-with-editable-table-mockup: The tags are presented in a table in read-only mode. When the user clicks on the "Edit" button, the table becomes editable inline. The user can make any number of changes and add or delete tags, and clicks on "Save" button to make a single API call to save all changes. We currently use this pattern in user profile page.
Updated by Radhika Chippada almost 7 years ago
- Status changed from New to In Progress
Updated by Radhika Chippada almost 7 years ago
Branch 9426-collection-tags @ 8eef061d1e3c8fcc03b89637e18c91e04689614f
Implements "editable table" layout for the collection tags.
Updated by Radhika Chippada almost 7 years ago
- Target version changed from 2017-06-21 sprint to 2017-07-05 sprint
Updated by Lucas Di Pentima almost 7 years ago
- File
apps/workbench/app/controllers/collections_controller.rb- Lines 366-369: Do you think this would be more readable by negating the conditional so there’s no empty block on the “true” case? For example:
if not @object.update_attributes…. self.render_error… end
- Lines 366-369: Do you think this would be more readable by negating the conditional so there’s no empty block on the “true” case? For example:
- Adding a duplicated key silently overwrites the first one, should this be checked to avoid changing previous values without notice?
- When having lots of tags, the bottom of the tag table will pass the browser boundaries. When the user clicks on “Edit”, it will have to manually scroll to the bottom to be able to see/access the rest of the action buttons (Add/Save/Cancel). Do you think it would be a good idea to scroll the page to the bottom when clicking “Edit”? Here’s an example https://github.com/GabrielDelepine/smooth-scroll
(The alternative would be to duplicate the buttons, but as the new tags are added to the bottom of the table, it makes no sense to have them on the top.) - Newlines on key and value are removed, is that correct behavior? If so, could we restrict the editable text box so that no newlines are accepted?
Updated by Radhika Chippada almost 7 years ago
@ c2a1539e64937b126c0090bc5d9fe8d65411be8f
File apps/workbench/app/controllers/collections_controller.rb -- Lines 366-369
Updated this to address a race condition with refresh and now there are no inconsistencies when saving tags (as seen towards the end of demo on Tuesday)
Adding a duplicated key silently overwrites the first one, should this be checked to avoid changing previous values without notice?
I expect the user to know (or to eventually know) that this is a hash table and keys won't be duplicated. I really do not think we can do much about this. Leaving this as is.
When having lots of tags, the bottom of the tag table will pass the browser boundaries. When the user clicks on “Edit”, it will have to manually scroll to the bottom to be able to see/access the rest of the action buttons (Add/Save/Cancel). Do you think it would be a good idea to scroll the page to the bottom when clicking “Edit”? Here’s an example
What if the user wants to edit the "first" / tags at the top of the table? I really don't think this would be a problem. The scroll bar is there to let the user know that there is "more" in the page, and to be frank the user couldn't have ended up with those many tags before entering the first tag etc. Leaving this as is until further feedback from someone like Bryan or other customers.
Newlines on key and value are removed, is that correct behavior? If so, could we restrict the editable text box so that no newlines are accepted?
This is a great idea. I updated the javascript and css to suppress new lines. Javascript to prevent typing newline characters and CSS to prevent pasting new lines from copied text.
Thanks.
Updated by Radhika Chippada almost 7 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset arvados|commit:a4127e018442e1b8053307f376c2d8c66b3279fc.
Updated by Radhika Chippada almost 7 years ago
- Status changed from Resolved to In Progress
Reopening to store tags as properties, not as a field in properties.
Updated by Radhika Chippada almost 7 years ago
Branch 9426-collection-tags-as-properties @ ef4ca87900bd023849aca62952ad2a27cfe40d34
Save tags as properties rather than as a field in properties.
Test run @ https://ci.curoverse.com/job/developer-run-tests/354/
Updated by Lucas Di Pentima almost 7 years ago
Reviewing updates at ef4ca8790.
LGTM, please merge.
Updated by Radhika Chippada almost 7 years ago
- Status changed from In Progress to Resolved