NASA-PDS / doi-ui

The web interface for the PDS DOI Service providing the ability management PDS archive DOIs. See the DOI Service for more details on the available capabilities. https://nasa-pds.github.io/doi-service/
Apache License 2.0
0 stars 4 forks source link

Pre-existing keyword show in a weird way in the UI #88

Closed tloubrieu-jpl closed 2 years ago

tloubrieu-jpl commented 2 years ago

๐Ÿ› Describe the bug

See for example doi 10.17189/22185 on pds-dev3

image

๐Ÿ“œ To Reproduce

  1. search for doi 10.17189/22185
  2. click update
  3. click published: yes
  4. edit keywords

๐Ÿ•ต๏ธ Expected behavior

The keywords should be in different subject tags

๐Ÿ“š Version of Software Used

๐Ÿฉบ Test Data / Additional context

๐ŸžScreenshots

๐Ÿ–ฅ System Info


๐Ÿฆ„ Related requirements

โš™๏ธ Engineering Details

eddiesarevalo commented 2 years ago

Looks like that subject (keyword) line was either entered that way or generated on the backend. Each subject should be only one keyword but that specific subject (keyword) is the string ['VOYAGER 1','JUPITER','ENERGETIC PARTICLE DETECTOR','VG1','PLANET','LECP','LOW ENERGY CHARGED PARTICLE']

I was working on parsing it out to show as separate keywords on the UI but then I realized it won't fix it on the backend. At this point there is nothing to prevent a user from entering whatever text they want as a subject (keyword) for example ?#&$#$)(*(akjskldfj. This should probably be rejected by the server.

According to @tloubrieu-jpl these should no longer occur and there is a user guide that lets a user know how to enter keywords.

I coudn't find any DOIs that still have a subject(keyword) like this. I have been testing by creating them to look like this particular way as doi 10.17189/22185 on pds-dev3 no longer exists.

@collinss-jpl Do you see any more that look like this? Otherwise we should close this as 'will not fix'

collinss-jpl commented 2 years ago

@eddiesarevalo I don't think we have any more existing entries like this where the keywords/subjects have been serialized out incorrectly. For this particular entry (10.17189/22185), I'm guessing it has already been deleted at some point since I cannot find it on DataCite either. You are correct though that for future cases, it should be corrected on backend first and foremost.

tloubrieu-jpl commented 2 years ago

We will close that since it sounds like we don't see this issue anymore.