Describe the bug
The importer supposedly supports DOIs pointing to the ACM Digital Library. Providing such a link fails with an error message saying a manual import is required.

To Reproduce
Steps to reproduce the behavior:

1. Go to Submit Artifact
2. Paste in "https://dl.acm.org/doi/10.1145/3474718.3474719" (no quotes)
3. Click "START IMPORT"
4. See error

Expected behavior
Importer should properly parse the DOI target and populate the import form with found information for refinement by the user.

Admin interface allows admins to filter and view only published artifacts. We need the same for unpublished artifacts.

catch all errors and display user friendly error messages.

Error messages are not user friendly or intuitive.

Add a button that allows a user to "claim" an artifact. This is important in cases where someone else/a 3rd party imports an artifact that they are not owners of. For example, artifacts can be added by anyone even if they aren't owners. When the owner logs in and they see the artifact, they should be able to say it is theirs and tie it to them.

This button should not automatically approve the claim. Instead, a notification should go out (email, admin interface, both?) to allow an admin or other approved adjudicator approve the claim. For now, Jelana has volunteered to handle approving this...but we should work out a long-term plan for more than one person being the owner of this process...or allow a current person that is allowed to approve these to give access to another person to approve without needing to update any of the backend code.

The database has a number of broken relationships. When a user clicks on the relationship, it doesn't work correctly. Check for these and fix manually.

Add the ability to, through the admin interface, edit a published artifact. This could be implemented by giving the admin the ability to toggle the publish bit on a single artifact: un-publish, edit, re-publish. This will allow us to quickly hot patch an artifact's hub entry as we work to get good, clean data in this initial phase.

Note: We may want to keep this for future use but by policy should use it judiciously.

Change artifact types from:

• dataset (OK)
• executable (<< covered by code)
• methodology (<< level?)
• metrics (<< level?)
• priorwork (<< relationship to another artifact)
• publication (OK)
• hypothesis (<< level?)
• code (OK)
• domain (<< attribute on an artifact)
• supportinginfo (<< relationship to another artifact)

To:

• publication
• presentation
• dataset
• software
• other

This will require rolling all existing code types to "software".

I have verified that the only existing artifact types are publication, dataset, and code, so no other DB changes are necessary.

Is your feature request related to a problem? Please describe.
When adding an artifact in arXiv.org, it is not clear which URL to use. Using the http://arxiv.org/pdf link results in an error. The system wants the http://arxiv.org/abs link.

Describe the solution you'd like
If the user submits the pdf link, automatically convert it to the http://arxiv.org/abs link. E.g.,

http://arxiv.org/pdf/2111.07847v1 => http://arxiv.org/abs/2111.07847v1
http://arxiv.org/pdf/2111.07847v1.pdf => http://arxiv.org/abs/2111.07847v1

Describe alternatives you've considered
Document what the link should be and rely on the user to get it right. This isn't as user-friendly.

Additional context
This issue came out of the 2021 ACSAC BoF.

Is your feature request related to a problem? Please describe.
Right now items are only returned based on the search terms. Users will need a way to pull different categories of items

Describe the solution you'd like
At least with search, we should have the ability to specify a category that we want to query on. This means that we need to be able to fetch the categories and add another search keyword to specify the category we want to pull items from.

Describe alternatives you've considered
Longer term we need the ability to define groupings and categories that go beyond the type of artifact, but that may be system defined or user-defined.

Additional context
The backend does not currently support this

Describe the bug
After searching for an artifact when we click on read more to get the complete information, it tried to load the artifact but then gives a Error loading message.

To Reproduce
Steps to reproduce the behavior:

1. Go to http://localhost:3000/search
2. Search for ciphertext as keyword
3. Click on read more of first result, gives a Error loading message
4. See error

Expected behavior
The Read more button should present more information about the artifact

Screenshots

Desktop (please complete the following information):

• OS: [e.g. iOS] Ubuntu 20.04
• Browser [e.g. chrome, safari] Firefox
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22] 89

Additional context
N/A

Change login button to "login via Github" so it's clear.

What if someone doesn't have Github account? (LT: We don't worry about this part of the comment now)

Right now, after searching for an artifact, clicking "Read More", and clicking "Back" saves your search results, but not your search form inputs. So, we need to save the inputs too, so that iterative refinement is possible and retyping is unnecessary. Of course, this will also necessitate a "clear form" widget, but that's easy.

Describe the bug
on a smaller screen, the lower info pane flows over the main area pane. additionally, the left nav bar flows over the lower information bar

To Reproduce
Steps to reproduce the behavior:

1. scroll to bottom of screen
2. shrink window down

Expected behavior
left nav pane should not flow over the bottom info bar
bottom info bar should not flow over main area

I see that the DOI points to a paper that has an artifacts badge on it. I'm just not sure what it means for a publication to be reusable. I think that actually it's the artifacts that are associated with the paper that are reusable, but when I click on the relationship to get the software, it does not have the artifacts badge. I think we need to "smartly" behind the scenes, move or at least copy the badge to the correct location when we import.

See artifacts 25 and 25 in the production server.

Need way to view the list of artifacts that I "own"
Right now, there is no way to view the list of artifacts that a user has imported (or taken ownership of, once implemented). Suggest we add an item to the left menubar: My Artifacts, that mirrors other pages but displays the list of artifacts that I own.

Describe the bug
On the "Search Artifacts" page, the "Back to Top" button can cover up the "Read More" button for an artifact. See the attached screenshot.

To Reproduce
Steps to reproduce the behavior:

1. Go to "Search Artifacts"
2. Search for "stackdb"
3. Scroll the window content down to the bottom
4. See error

Expected behavior
The window content would scroll up enough so that the "Read More" button for the last artifact would be clickable.

Desktop (please complete the following information):

• OS: macOS 10.14.6
• Browser: Firefox 93.0

Thinks it would be better to explain Github permission rules during account creation rather that in the FAQ. People will likely just go to account creation without reading the FAQ.

Add a link to the Best Practices guide for artifact curation on the left hand side, next to the FAQ link.

https://searcch.cyberexperimentation.org/best-practices

readme.MD only shows up for code. Needs to show up for data.

A Venue is yet another "first class" piece of Artifact Metadata, that represents a place of publication or appearance. We attempted to cover all know publication kinds that we could plausibly receive. We want users to be able to attach one or more Venues to an Artifact, since an Artifact could be "published" or appear in multiple places. This is important to be able to provide Venue-indexed lists of Artifacts.

The schema is at https://gitlab.flux.utah.edu/searcch/importer/-/commit/27b2785ced42c4192b12d8a4ce4e76e5c2fc6e00 , and will shortly be merged with importer master.

Venues are similar to existing objects like Badges or Organizations in our system, in that Venues are either verified or unverified. However, they are dissimilar to Badges in that we do not allow users to create Badges (yet), since the set of Badges is finite and knowable. Orgs and Venues are effectively infinite, so we allow users to create them, but in that case, they are not marked verified. The importer knows how to collect Venue information for some sources now.

The backend work is simply the database migration and a few basic endpoints that are clones of Organizations. Similar for the frontend.

Is your feature request related to a problem? Please describe.
The set of relationships we have assumes you are adding the relationship on a publication or software artifact-- the system only has the set of forward > relations (cites, extends, supplements, describes, processes, produces, requires). We purposely limited the set to reduce the number of options a user must consider.

When adding the relationship on the right-hand side artifact (e.g., the publication describes software, but adding on the software artifact, the relationship is really "software is described by publication", but the only option is "describes". This is confusing.

Describe the solution you'd like
Change the options in the UI to "describes / described by" (for example), so the user chooses the type of relationship.
Under the covers, derive the correct directions and assign appropriately so the relationships read:

• publication describes software
• software is described by publication

This should work for describes/described by, processes/processed by, and produces/produced by for publication/software, publication/dataset, and software/dataset. cites/cited by, extends/extended by, supplements/supplemented by and requires/required by (for publication/publication and software/software) cannot be inferred, so users will have to get that right.

An additional improvement would be to only show the valid options based on the two types. During the 2021 ACSAC BoF, the Rafael started to select supplements/supplemented by for linking the publication and software artifact. If the source artifact is type publication and the destination artifact is type software, the system could automatically choose describes/described by. if the source is software and the destination is dataset, the system could present only the processes/processed by and produces/produced by relationships.

In thinking about it, maybe the options should be:

• Publication to publication

  • cites
  • cited by
  • extends
  • extended by
  • supplements
  • supplemented by

• Publication to software or dataset

  • describes/described by

• Software to dataset

  • processes/processed by
  • produces/produced by

• Software to software

  • requires
  • required by

We may also want to add the description in the selection text just to help further guide users.

This would do two things: 1) guide users to select our intended relationships to keep the metadata clean and consistent and 2) reduce the cognitive burden on the user in trying to select the right relationship.

Describe alternatives you've considered
Add all the relationship options back, regardless of the artifact types, which will lead to users choosing the wrong relationships and the metadata being polluted.

Additional context
Here's the table of relationships we "desire":
https://searcch.cyberexperimentation.org/best-practices/artifact-relationships

This issue came out of the 2021 ACSAC BoF.

Having the default search be over just data and software is confusing users.

Change the default artifact type to all artifacts.

This came out during the 2021 ACSAC BoF.

Begin with Tim's https://github.com/ITI/releasing-experiment-artifacts

Refine to include:

• Discussion of different artifact types
• Guidance on relationships
• Guidance on keywords
• Guidance on packaging for (e.g.) github -- inc. README.md files
• Templates for different types of artifacts (e.g., software that implements a research algorithm vs. infrastructure such as traffic generators)

Is your feature request related to a problem? Please describe.
Right now favoriting an item is stubbed only, and is not logged or maintained anywhere.

Describe the solution you'd like
Tie the mockup to the backend, as the backend is exposed.

Additional context
Backend functionality does not yet exist.

After taking ownership of a record and clicking on Edit New Version, the edit dialogue is displayed.
If you enter an additional file URL, the SAVE and PUBLISH buttons remain inactive.
Entering something in the description field activates these buttons, but then the README.md file is no longer displayed because the description field overwrites it.

The code should activate the SAVE/PUBLISH buttons if any changes have been made to any field in the record.

Update question:
'I have code, data, and other artifacts that are all from the same research. How should I submit those to the hub?',

with answer:
'Generally, code and data should be packaged and submitted separately into logical components, unless the code is used to generate the data. The hub supports the ability to link artifacts that are related. Please see the best practices and considerations for SEARCCH hub curation for more information.'

Note that I tried updating the FAQ.vue page, but the master branch did not match what was deployed on hub. or hub-dev. It looks like this still lives in an old branch that should have been merged into master. Somehow it got pushed into production without merging.

This update needs to be done concurrent with pushing out the new version to the production environment.

When adding an author to an artifact, the system should look for users who match the author and allow a SEARCCH user object to be added as an author. Or -- allow the submitter to choose an existing user as an alternative to inserting author information.

Change artifact relationships to support additional and reverse (two-way) relationships.

Currently supported relationships:

• cites
• supplements
• continues
• references
• documents
• compiles
• publishes

New relationships:

• cites
• cited by
• supplements
• supplemented by
• extends
• extended by
• uses
• used by
• describes
• described by
• requires
• required by
• processes
• processed by
• produces
• produced by

This will allow us to represent the following relationships and enhance usability in that users will be able to get to a related artifact regardless of whether they are viewing the artifact on the left or right side of the relationship.

artifact	>	        <	            artifact	Notes

paper	    cites	    cited by	    paper	    General citation of another paper

paper	    extends	    extended by	    paper	    Work described in paper builds on another prior work (stronger citation)

publication supplements supplemented by paper       Detailed technical report or dissertation provides supplemental material for published paper
  
paper	    describes	described by	software	Paper describes an algorithm or function that is implemented in software

paper	    describes	described by	dataset	    Paper describes dataset (can be input or output)

paper	    uses	    used by	        dataset	    Work described in paper uses dataset

paper	    uses	    used by	        software	Work described in paper uses software

software	processes	processed by	dataset	    Software processes an input dataset

software	produces	produced by	    dataset	    Software produces or creates an output dataset

software	requires	required by	    software	Software requires another piece of software to work (may never get used)

Required database artifact relationship entry changes are:

• continues -> extends
• references -> cites
• publishes -> uses

This issue focused on the available relationship strings in the system. The implementation of any automated two-way relationships is captured in this issue: #47

Look at the README.md file here: https://github.com/icsdataset/hai
Then look at how it is displayed here: https://hub.cyberexperimentation.org/artifact/512

Describe the bug
When importing from a DOI, the importer creates/suggests duplicate keywords with different cases (e.g., "Test" and "test").

To Reproduce
Steps to reproduce the behavior:

1. From the SEARCCH importer, import "https://dl.acm.org/doi/pdf/10.1145/3474718.3474726"
2. Click on Edit
3. Look at the keywords extracted

Expected behavior
Importer should filter keywords using a case insensitive filter.

Screenshots

Desktop (please complete the following information):

• OS: MacOS
• Browser Firefox
• Version 93.0 64-bit

Smartphone (please complete the following information):
n/a

Additional context
Add any other context about the problem here.

Describe the bug
When inputting a new role (new author for manual artifact import) it is unclear to user how to input multiple authors

To Reproduce
Steps to reproduce the behavior:

1. Go to manual artifact import
2. Click on + for the role
3. Dialogue doesn't make it clear if one can input multiple authors on the same line, like one would for a paper

Expected behavior
A line of guidance that says "Input multiple authors separately, one at a time"

Additional context
I think we should rename Role to Author since the dialogue is clearly "Add Author".

Is your feature request related to a problem? Please describe.
Comments are currently mocked with lorem ipsum text

Describe the solution you'd like
Map the mocked capability to the backend.

Describe alternatives you've considered
Eventually we want to move to using something like discourse instead probably, but likely not in the immediate term.

Additional context
Backend interface to comments does not exist yet.

At present, the "Best Practices" menu item takes the user to the searcch.cyberexperimentation.org web site.

We should move this information directly to the hub.

Describe the solution you'd like
At an appropriate place in the SEARCCH hub website, add a link to the CCRI-VO website, https://www.ccrivo.org/

Maybe at the bottom of the front page and in the FAQ, add something like this:

The SEARCCH hub is community infrastructure supported by the National Science Foundation's CCRI and SATC programs. Visit the CCRI-VO website to discover other infrastructure supported by the CCRI program.

Background
NSF has funded a "CCRI Virtual Organization" (CCRI-VO). As described at its website, https://www.ccrivo.org/about/

The CCRI Virtual Organization (CCRI-VO) exists to help users understand and utilize the many different computing infrastructures available to them under CCRI. To achieve this purpose, CCRI-VO keeps a centralized list of infrastructures that CCRI has funded, as well as documentation for using those infrastructures.

Eric Eide is a current member of the the CCRI-VO Council (i.e., advisory board).

To help increase the visibility of its website, the CCRI-VO is asking CCRI-supported projects to link from their websites to to the CCRI-VO website.

Aside, here is the (partial) description of SEARCCH in the CCRI-VO website: https://www.ccrivo.org/projects/sharing-expertise-and-artifacts-reuse-through-cybersecurity-communityhub-searcch/

Eric Eide is "on the hook" for helping the CCRI-VO complete this entry. He'll probably be asking for help!

Describe the bug
On the "Manage Account" page https://hub.cyberexperimentation.org/profile — if I delete the initial empty affiliation, I get an "Internal Server Error" with status code 500.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://hub.cyberexperimentation.org/profile
2. Click on X in the iniial empty affiliation: '( (X))"
3. See error

Expected behavior
I expected the widget for the initial empty affiliation to be deleted. (When I did first did this "for real," I entered my affiliation in a second text-entry "bubble." I went to delet th now-unneedd empty bubble, and boom!)

Screenshots

Desktop (please complete the following information):

• OS: macOS 10.14.6
• Browser: Firefox
• Version: 91.0

We should migrate to nuxt/auth v5 so we can take advantage of its built-in support for refresh tokens (https://auth.nuxtjs.org/schemes/refresh). This will allow us to stop hijacking the browser to force the user to redo the SSO login dance.

Is your feature request related to a problem? Please describe.
The current workflow for searching is not intuitive. When using the non-advanced search and just entering a keyword, people think it's searching everything when in fact it is only searching values in the description and title.

Describe the solution you'd like
Change the workflow as follows:

When using the simple search, perform the search over all fields and return all matches.
Clicking on advanced should open a dialog that has an explicit value box for every field. So, for example, there should be a title field and a description field, separately. We should also have an "and" "or" option people can select. Currently the search performs an "and" function. Users may want to look for a word in any of several fields.

Describe alternatives you've considered
None

Additional context
This came out of the 2021 ACSAC BoF.

1. Need to create a multi-select dropdown with options for artifact, user, and organization.
2. Pass the selected options under the entity list to the /artifact/search endpoint
3. Render the list of artifacts, users and/or organizations returned under separate headings/tabs in the UI.

Describe the bug
Add review button doesn't add a review/rating.

To Reproduce
Steps to reproduce the behavior:

1. Go to http://localhost:3000/search
2. Search for ciphertext and locate the first artifact, click on the comment icon on the bottom left corner
3. Enter a review and press send review
4. No request is sent when network section is analyzed with dev tools.
5. Similar behaviour for ratings

Expected behavior
A backend request needs to be sent and appropriate rating/review must be added to the database

Screenshots

Desktop (please complete the following information):

• OS: [e.g. iOS] Ubuntu 20.04
• Browser [e.g. chrome, safari] Firefox
• Version [e.g. 22] 89

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
N/A

right now when adding a relationship, the user is only presented with search field. Vivek has added an api to the backend -ITI/searcch-backend#31 to get recommended relationships. We should use that instead of the search box by default.

The Google metaphor goes a bit too far.
"We should explain that we are not crawling anything, they have to submit artifacts"

ORCiD is becoming a standard for researchers.

In addition to email contact info, we should also support entering/saving an ORCiD for

1. user profiles
2. authors (when creating artifacts)

If user inputs a URL of an existing, published artifact, user should be warned and given a link to see if their goal is already met. This can be a false negative if user is reusing said URL for an artifact of different type, but those cases should be rare.

If a user imports an artifact using a one-way relationship, the system should automatically create and display the reverse relationship between the two related artifacts.

E.g.,

Paper1 cites Paper 2 << user entered
Paper2 cited by Paper1 << system created

How this is implemented is TBD and up to the development team. Two approaches have been discussed:

• Importer automatically creates the static reverse relationship at publish time
• Front end dynamically generates and displays the reverse relationship when an artifact is viewed.

This issue relies on resolution of #46

Is your feature request related to a problem? Please describe.
Beta launch doesn't have the ability to authenticate a user yet

Describe the solution you'd like
Change stubbed github auth for development team into formalized github auth to prepare for beta launch.

Additional context
Would also be useful to have the authenticated user profile linked in to the authentication as well.

Currently the Start Over link goes to the About route, or somthing. We would ideally like to retry if at least the initial route load succeeded (if not, we don't want to loop, so have to redirect to somewhere safe).

Right now, relationships are displayed using the artifact ID number which isn't very meaningful. We need to rethink how we display these relationships -- perhaps in a list and using the artifact title -- so it is more meaningful to the user.

We may need to also have the ID in the event that there are duplicate titles in the system, although under the covers, if a user clicks on the relationship, the system will take him/her to the the correct related artifact.

Describe the bug
Adding an article to favourites using the heart icon sends a post request with userid: null

To Reproduce
Steps to reproduce the behavior:

1. Login to the localhost:3000 search frontend website using github
2. Search for an artifact and click on favourite icon
3. Use dev tools to observe the request, it sends userid param as null

Expected behavior
Artifact must be added to the favourites list

Screenshots
Probable cause that userid is null:

Desktop (please complete the following information):

• OS: [e.g. iOS] Ubuntu 20.04
• Browser [e.g. chrome, safari] Firefox
• Version [e.g. 22] 89

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
N/A

Describe the bug
FAQ window is too narrow, isn't responsive, and splits words oddly when wrapping text

To Reproduce
View the FAQ and look at "I have code, data, and other artifacts that are all from the same research. How should I submit those to the hub?". The word "research" is split as "resear" and "ch".

Expected behavior
Resizing the window should change the size of the text box. Carriage return should be inserted before the word if there's not enough space on the line for the entire word.

Screenshots
See screen shot

Desktop (please complete the following information):

• OS: [e.g. iOS] MacOS
• Browser [e.g. chrome, safari] Firefox
• Version [e.g. 22] 104.0.1 64-bit

Additional context
Overall, the text box width is fixed and too narrow. The box should be responsive and resize when you resize the screen.