Closed TaniaSchlatter closed 5 years ago
TaniaSchlatter
commented
5 years ago Adding the ability to add data from the header means that users need to be able to select the dataverse and/or dataset that they want to deposit data to or create a dataverse in. We would want to show users the dataverses they have permission to add to. This needs to be thought through for admins so that we do not show all options.
mheppler
commented
5 years ago [SORRY: Mistakenly left this comment on the wrong issue on 3/8.]
Adding this feature should including resolving this issue, Moving Dataverses + Datasets: Provide way in the UI for a user to do this #2073.
The navbar contains links for actions at the root/installation level. When you sign up for an account, the account is created at the highest level. When you use the search input, you are searching all contents of the root/installation. Following that logic, clicking "Add Data" would deposit the dataset/dataverse into the root dataverse, which goes against the preferred workflow, of depositing datasets into your own dataverse.
[ALSO: Adding comments from other related issues that were closed as those issues were consolidated into this issue.]
@ajirnyi commented on Jan 14, 2016 in issue #2874
When the base URL is long enough (e.g. 49 symbols in our test case), the Identifier entry field is too short except for very wide browser windows, and it is not possible to see the text entered there (see example below). The issue is most noticeable in Firefox (box is too small up to screen width of 1183 pixels, after which it instantly expands), but is present in all browsers.
...
@kaitlinnewson commented on Oct 17, 2017 in issue #4212
Hi Harvard team!
We received a report from one of our users about display issues on the 'Create a new dataverse' page. I've tested this in both the Scholars Portal instance and the Harvard instance, have tested in Chrome (v 61.0.3163.100) and Firefox (v 56.0), and am using OSX 10.11.6.
The issue seems to happen at a screen width of 990px or less, and causes text overlap and the inability to see text entered into the identifier field. I've attached a couple of screenshots for reference.
Let me know if you need any more information!
djbrooke
commented
5 years ago @TaniaSchlatter I moved this over to the design column on the board. Feel free to move back to inbox if this is not the correct status.
TaniaSchlatter
commented
5 years ago Related issue #5493 (closed), #5874: Push researchers towards Dataverse Creation and Dataset Linking from Journal Acceptance Notifications
TaniaSchlatter
commented
5 years ago Docs that break down:
pdurbin
commented
5 years ago Related: As the creator of a dataverse I'd like to know how to make an "Add Data" button appear for non-logged in users to encourage user interaction #5718
djbrooke
commented
5 years ago mheppler
commented
5 years ago Outline of the moving parts:
navbar
edit/create dataverse form
view dataverse pg
edit/create dataset form
view dataset pg
view file pg
contact form
my data
user guide
release notes
OUT OF SCOPE
edit/create dataset form
mheppler
commented
5 years ago After reviewing the progress on the to-do list above, we have revised the final scope to break off some accessibility improvements for another development effort. What remains is the backend review/refactoring/optimization of the Host Dataverse dropdowns that were added to the create/edit dataverse and dataset forms, as outlined in Danny's comment above.
- Noted some performance concerns about the dataverses list, but we've done work in this area so it may now be more performant (caching? does changing host update dataverse metadata fields? does changing host update dataset template dropdown?)
That part of the scope is represented in the unchecked "host dataverse backend" items for the create/edit dataverse and dataset forms, in the to-do list above. This issue is ready to pick up by any developer ready to tackle those final development items. Meanwhile, I will be adding release notes and documentation changes to check off the last outstanding to-do items.
mheppler
commented
5 years ago Revised the remaining backend to-do list items to be more specific, requiring a review of the functionality and refactoring of the code that was original to 4.0-beta and most likely hasn't been touched since.
Also, after reviewing with @landreev, @scolapasta and @djbrooke, added new to-do items to wire up a form/page refresh upon select/change in order to update dynamic content on the page (e.g. breadcrumbs, Metadata Fields and Browse/Search Facets on the dataverse form, Dataset Template on the dataset form).
There are most likely UI implication on the dataverse form with this change (most Host Dataverse component to top of form, like the dataset form), that we should review once a demo of the refresh functionality with @TaniaSchlatter is possible.
mheppler
commented
5 years ago Moved host dataverse select component on dataverse form, added bundle info msg (see screenshot, attn: @TaniaSchlatter). Added same info msg to the host dataverse select component on the dataset form as well.
@landreev ~notice a bug on the create dataverse form that would not forward the user after clicking Save Changes from the form to the success msg view on the new dataverse pg. Manually navigating to the root dataverse pg however would show you the new dataverse was in fact created.~
TaniaSchlatter
commented
5 years ago Thanks @mheppler. The "Changing the host dataverse..." text is a little odd since fields are populated by default, but I'm ok with moving it forward as is.
Having the "Dataverse" field say "Dataverse Name" helps clarify.
mheppler
commented
5 years ago @landreev Revised my comment about to strike the bug report, as I saw the same issue on develop and was able to finally make it to the success msg after starting everything and giving the page a longer wait time than I may have previously.
landreev
commented
5 years ago One thing both @mheppler and I noticed, when creating a new dataverse, you see the following message in server.log:
unable to index dataverse. id was null (alias: anothertest)it is extra weird, because the new dataverse you have just created does actually get indexed successfully; so it's a false alarm of some kind. This is NOT something introduced in this branch - I checked the logs in prod.:
# grep 'unable to index dataverse' server.log_2019-10-*
server.log_2019-10-01T13-57-08: unable to index dataverse. id was null (alias: garlick_auto)]]
server.log_2019-10-02T14-16-54: unable to index dataverse. id was null (alias: uoregon)]]
server.log_2019-10-03T12-02-00: unable to index dataverse. id was null (alias: lysi)]]
server.log_2019-10-03T12-02-00: unable to index dataverse. id was null (alias: PSVMOU)]]
server.log_2019-10-03T14-06-27: unable to index dataverse. id was null (alias: Meerow)]]
server.log_2019-10-04T07-11-36: unable to index dataverse. id was null (alias: ywiratamajemm)]]
server.log_2019-10-04T12-57-37: unable to index dataverse. id was null (alias: PEDPEFC)]]
server.log_2019-10-04T14-18-11: unable to index dataverse. id was null (alias: stevenmvanhauwaert)]]
server.log_2019-10-04T16-04-35: unable to index dataverse. id was null (alias: hms-genetics)]]
server.log_2019-10-06T00-30-24: unable to index dataverse. id was null (alias: yangyangzhou)]]
server.log_2019-10-08T10-28-03: unable to index dataverse. id was null (alias: weather_radar)]]
server.log_2019-10-09T02-51-34: unable to index dataverse. id was null (alias: Kolya)]]
server.log_2019-10-09T02-51-34: unable to index dataverse. id was null (alias: Amelita)]]
server.log_2019-10-10T17-15-24: unable to index dataverse. id was null (alias: DALYs)]]
server.log_2019-10-12T02-01-52: unable to index dataverse. id was null (alias: keithchen)]]
server.log_2019-10-12T14-06-11: unable to index dataverse. id was null (alias: foolishnessprototypes)]]
server.log_2019-10-16T04-29-13: unable to index dataverse. id was null (alias: SM)]]
server.log_2019-10-16T04-29-13: unable to index dataverse. id was null (alias: DrManishGehani)]]
server.log_2019-10-17T15-29-07: unable to index dataverse. id was null (alias: foobar)]]
server.log_2019-10-17T19-22-56: unable to index dataverse. id was null (alias: byers)]]
server.log_2019-10-18T05-55-38: unable to index dataverse. id was null (alias: dkf)]]
server.log_2019-10-18T05-55-38: unable to index dataverse. id was null (alias: lemola)]]
server.log_2019-10-18T15-54-18: unable to index dataverse. id was null (alias: m2filaments)]]
server.log_2019-10-22T08-35-48: unable to index dataverse. id was null (alias: dividendindia)]]
server.log_2019-10-22T17-33-11: unable to index dataverse. id was null (alias: DFCpastoral)]]
server.log_2019-10-23T11-30-23: unable to index dataverse. id was null (alias: pnas_dropletafm)]]
server.log_2019-10-23T11-30-23: unable to index dataverse. id was null (alias: testtesttest)]]
server.log_2019-10-23T16-02-33: unable to index dataverse. id was null (alias: RandyCragun)]]
server.log_2019-10-24T08-59-03: unable to index dataverse. id was null (alias: fomin)]]
server.log_2019-10-24T18-06-43: unable to index dataverse. id was null (alias: GUD_CS510)]]
server.log_2019-10-28T13-40-58: unable to index dataverse. id was null (alias: jclark10)]]
server.log_2019-10-29T05-11-04: unable to index dataverse. id was null (alias: nmhhg8)]]I'm opening a new issue for this; curios what's going on (maybe there's an extra index call somewhere in the create dataverse command, that tries to index a stale dataverse copy that hasn't been persisted yet??). But it doesn't appear to be a fatal condition.
landreev
commented
5 years ago Created #6337 for the above.
landreev
commented
5 years ago Mr. @mheppler and I had an executive conference and made a decision to close the to-do checklist and advance this issue on its natural course across the project board.
landreev
commented
5 years ago There are a couple of verbose debugging messages left in the code; specifically, the following:
New host dataverse id: 79610
Created a new new dataverse.in server.log when selecting a new host dataverse. I'd like to keep these in place during QA, and remove them when we're ready to merge.
landreev
commented
5 years ago @mheppler So I switched from the selectOne pulldown menu, to the autoComplete setup similar to what we have in the linking popups. Could you please take a look at the branch and see if any cosmetic readjustments are needed?
mheppler
commented
5 years ago Cleaned up the markup and CSS for autoComplete component on edit dataverse and dataset forms. This will also improve the consistency of other instances of this component across the app, like in the link dataset, create group, assign roles and other workflows. There is no change to the functionality of the component, just improving the consistency of the width and padding of the component in the form compared to other form components on the page.
@landreev will clicking around on the create/edit dataverse and create/edit dataset versions of these forms, I stumbled across two issues that need to resolved:
emptyMessage attribute (see example on dashboard-datamove form)landreev
commented
5 years ago @mheppler OK, checked in fixes for the 2 things above.
landreev
commented
5 years ago The issue mentioned in the PR appears to be the result of primefaces autoComplete giving us trouble; it also looks like it's something we've seen on another page before. Parking it in dev., we'll be working on it first thing next week.
mheppler
commented
5 years ago Various references for autoComplete/duplicate ID's:
One way to have people create more dataverses is to make it easier to see how to do it. People who get to dataverse from google and bypass the home page or search results page don't see a clear way to add data.
One solution: adding a button to the header on every page will help make it clear how to add to Harvard Dataverse.
Adding a button. The button has a dropdown to select a new dataverse or new dataset, as current Add Data functionality from the buttons on the home page:
If users are not logged in, the Log in/Sign in popup with a link to sign up (issue #6170) is shown. Proposed flow:
Removing the "Add Data" button from the search results page, and showing it on the header for not logged in users: