Uploaded image for project: 'DSpace (LEGACY)'
  1. DSpace (LEGACY)
  2. DS-4371

Integration/authorities endpoint delivers non-existing form-value pairs or controlled-vocabularies

    XMLWordPrintable

    Details

    • Attachments:
      0
    • Comments:
      2
    • Documentation Status:
      Needed

      Description

      The following REST API call delivers the “common_types” form-value-pairs:

      host/api/integration/authorities/common_types/entries?query=&metadata=dc.type&uuid=a7fd0586-c098-4b2e-966b-c6b13fc8e96a&page=0&size=100

      A call to a non-existent form-value-pair with the same request paramaters also the delivers the “common_types” form-value-pairs. Note the “non_existing_form_value_pair” url segment in the following REST API call:

      host/api/integration/authorities/ non_existing_form_value_pair /entries?query=&metadata=dc.type&uuid=a7fd0586-c098-4b2e-966b-c6b13fc8e96a&page=0&size=100

      The REST API above call should trigger a  404 error response as a form-value-pair with the name “non_existing_form_value_pair” does not exist at the backend.

       

      The same bug can be witnessed for controlled vocabularies. The following REST API call delivers the controlled vocabulary named “scrs”:

      host/api/integration/authorities/srsc/entries?query=&metadata=dc.subject&uuid=a7fd0586-c098-4b2e-966b-c6b13fc8e96a&page=0&size=100

      A call to a non-existing controlled vocabulary with the same request paramters also delivers the “scrs” vocabulary. Note the “non_existing_controlled_vocabulary” url segment.

      host/api/integration/authorities/ non_existing_controlled_vocabulary /entries?query=&metadata=dc.subject&uuid=a7fd0586-c098-4b2e-966b-c6b13fc8e96a&page=0&size=100

      The REST API above call should trigger a  404 error response as a controlled vocabulary with the name “non_existing_form_controlled_vocabulary” does not exist at the backend.

      There is another bug related to the above described behavior of the REST API. If two form_value_pairs exist at the backend (e.g “common_identifiers” and “common_types”) and the “common_types” form value-pair is used in submission-forms.xml e.g.

      <row>
          <field>
              <dc-schema>dc</dc-schema>
              <dc-element>type</dc-element>
              <dc-qualifier></dc-qualifier>
              <repeatable>true</repeatable>
              <label>Type</label>
              <input-type value-pairs-name="common_types">dropdown</input-type>
              <hint>Select the type(s) of content of the item. To select more than one value in the list, you may
                  have to hold down the "CTRL" or "Shift" key.
              </hint>
              <required></required>
          </field>
      </row>

       

      The following REST API call delivers the “common_types” form-value-pair:

      host/api/integration/authorities/common_types/entries?query=&metadata=dc.type&uuid=a7fd0586-c098-4b2e-966b-c6b13fc8e96a&page=0&size=100

      But a call using the same request parameters and another  form-value-pair (that exists at the backend) as a url segment returns the wrong form-value-pair:

      host/api/integration/authorities/common_identifiers/entries?query=&metadata=dc.type&uuid=a7fd0586-c098-4b2e-966b-c6b13fc8e96a&page=0&size=100

      One expects to get the “common_identifiers” form-value-pairs form the last REST API call. Instead the “common_types” form-value-pairs are delivered.

        Attachments

          Activity

            People

            Assignee:
            bollini Andrea Bollini (4Science)
            Reporter:
            julius.gruber Julius Gruber
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: