SSDM-8543 : V3 returning too much - changed v3 translation cache to reuse an already translated object only if it was translated with exactly the same fetch options (before one instance of an object would be reused across the whole results even if it was requested to be fetched with different fetch options in different parts of the results; this single instance would contain a sum of all fetch options the object was requested with; because of this behaviour far more data could have been returned than actually requested)

SSDM-8277: withCodes() added and tested for TagSearchCriteria, ExternalDmsSearchCriteria, AuthorizationGroupSearchCriteria, DataStoreSearchCriteria, CustomASServiceSearchCriteria

SSDM-8277: withCodes() added and tested for AbstractEntitySearchCriteria, EntityTypeSearchCriteria, ProjectSearchCriteria, SpaceSearchCriteria, VocabularyTermSearchCriteria

SSDM-8274: forbid nested withChildren(), withParents() and withContainer() for DataSetSearchCriteria

SSDM-7142: withAndOperator() and withOrOperator() added for ExperimentTypeSearchCriteria, SampleTypeSearchCriteria, DataSetTypeSearchCriteria, MaterialTypeSearchCritera in Java and JS. Tests added.

SSDM-7602 : openBIS v3 API: Search by Identifier using any field when not globally return no results

SSDM-7399: Using Array.prototype.slice.call() instead of Array.from() which should also work on jenkins

SSDM-6228: add 'archiving requested' to lucene index and allow to search for it. System tests in Java and JS for this search written.

SSDM-6228: change in PhysicalDataUpdate in order to be similar to other update classes. Java and JS tests exetended to test updating 'archiving requested' to true

SSDM-2371 : V3 AS API Generate Identifiers - compatibility with GeneralInformationService.generateCode

    - added missing check to V3 updateQueries method

- added missing database label to V3 Query class
- added missing check to V3 createQueries method

SSDM-5852 : V3 API Query - fix a general json deserialization problem - in some case, e.g. when a Map is returned with keys which are numbers, order of objects in textual json representation returned by the server is different than the order of objects in memory in JS after parsing this json. Because of this difference the deserialization was failing.

SSDM-6205 : V3 AS API Batch Imports - Expose legacy methods using AS service - ignore pure server-side classes in "js vs java" test

SSDM-5722 : V3 API: Search/Get/Update users with web properties - fix FetchOptionsMatcher to properly handle person webapps ("java.lang.IllegalArgumentException: wrong number of arguments")