Bugs in clients 7.0

Hello, during the adaptation of the openBIS for our lab I have encountered multiple bugs and unexpected behavior in the clients, mainly in pybis.

Javascript:
src/v3/util/Json.js:116
you are converting jsonId natively to boolean in the condition, which causes id=0 to be evaluated as false and not mapped. This is not a problem for the response from the server, as it sends ids from 1, but the client encodes ids from 0, so it is not possible to encode then decode the object on client only. Which admittedly sounds like a weird use-case, but it is useful for serialization of the objects for SSR or similar.

Another thing is that dependency on the jquery and other browser-only libraries makes the client basically unusable anywhere else, such as node.js, so React and other frameworks. I know it can be imported dynamically, but then the SSR and Server Components are unusable as the data cannot be fetched on the server. I personally repackaged the client in a way where it is not necessary and it is usable server-side, but I think it would be generally useful not to have it browser depended.

Pybis:
definitions.py:86
there is comma after showParentMetadata which makes it impossible to get them.

openbis_object.py:207
It happened to me that the deletion_id was None, and then it crashed on this line

property_reformatter.py:69 and 71
Adding string to an array with += causes the string to break into characters in the list. Instead I would add new items with .append() function

pybis.py:5681
Searching sample type codes with StringStartsWithValue causes to return unexpected results, especially with sample codes that share the same prefix. For example if user inputs “DEVICE_PART” they expect to get type groups for type “DEVICE_PART” and not also “DEVICE_PART_INSTANCE”, etc. The same for the type groups. Instead, I would expect to be able to search with wildcard pattern if I want the sample to start with a prefix like so “DEVICE_PART*”, but that is only a personal preference.

utils.py:237
I would expect this string to have the ‘r’ prefix so the backslashes are not interpreted. re.match(r"...", ident).

And in general I noticed that pybis struggles with the decycled objects from backend. If the object is referenced only by Id within the response, because it has been defined earlier in the response, it returns only the id as string and not the object itself, which creates weird situations where the same code works and does not, depending on the state of the database and connections within it. I noticed this with the typegroups search, when multiple types are returned and some of them belong to the same group, the group definition itself is readable only on the first object, and then the following ones just use @id=x instead as the attribute, so suddenly instead of the type definition one gets a string.

But in general I really love the changes you made to the 7.0. The multivalue/array types, type groups and the AFS is great. It allowed me to do what would have been very difficult without them. Good job, keep up :grinning_face:

Dear David,

Regarding Javascript:

Thanks for your report. Totally agree that the fact the javascript api requiring jquery is a waste.

The new Javascript API for the new Datastore server doesn’t have such dependencies but we are still paying technical dev from older APIs to ensure backwards compatibility on the general application server api.

If you have any prototype that ensures same serialisation mechanism we could take it as a starting point, probably striping that part from jquery as an internal lib would a good start.

We will eventually get there when priorities align.

Regarding Pybis:

We will go though your report and fixing bugs where makes sense on a future update.

Thanks for your report!

Juan

We found a slightly annoying issue with the new startup script of openBIS 7 (openbis.sh): After using openbis.sh, it keeps forwarding the log messages from the individual services (AS, DSS, AFS, etc) to STDOUT, even after the script has finished:

The scripts ends in the first line with “all services started successfully”, returns to the command prompt, but the individual start scripts keep logging until you send “exit” (Which also runs “exit” as a regular terminal command).

Hello again (and sorry :sweat_smile: ),

I have encountered an unexpected behavior when handling permissions. When asking for authorizationGroups and roleAssignments of a particular person the server returns empty array, unless the person who is asking (current user) is not an admin in at least one of the spaces (any). And it does not matter who is the Person the request is about or what space/project I am asking about. I would expect that at least every user can request their own roleAssignments and authorizationGroups in general (with role assignments to the groups). Which would be very useful for showing/hiding certain actions in the UI. And then asking for authorization of someone else than the user who is asking, needs to be an admin of the space/project they are asking about, or generally an admin. The fix for this is fairly simple, every user needs to be an admin of some space (so for now I have created an empty space where everyone is an admin, but this is suboptimal).

This is connected to another problem with getRights() call. It does not correspond with the authorizations. In a scenario where an user is set as admin or user on space and then on project (that is within the space) they are set as observer. When the user tries to edit a sample within the project the server correctly refuses the edit. However the getRights() endpoint returns UPDATE right on the same sample, which seems contradictory.