Do not rely on DataSourceId for UserAccessRequest, it does not match annotations, exports

[fm3]

Currently, we encode annotation ids and export ids in DataSourceId, to pass it around as payloads for UserAccessRequests. That doesn’t really make sense. A more generalized id type is needed, or some other design.

[fm3]

I hope that we can just use a single ObjectId after #8384

[frcroth]

Right now (after #8708 has been merged), we are still using some DataSourceIds for access checking:

• readDataSources is used in the LegacyController for legacy routes. We could query the datasetId first and then do the user access check for the datasetId.
• deleteDataSource is used in the DataSourceController for cancelling uploads, since uploads still work with DataSource ids generally.
• writeDataSource is used in the DataSourceController for uploads.

Otherwise we are using datasetIds (virtual datasets), annotationIds, tracingIds, jobIds; But administrateDataSources uses organizationId, which is not an ObjectId.

[fm3]

Thanks for having another look at this! Ok, I wonder if we could adapt uploads to use datasetIds as well?

For LegacyController I agree, we could fetch the id first.

The fact that organizationId is not an ObjectId is a pity in many ways, but I think we have to live with that for the time being. So I guess we could use a String for this request (and validate it as ObjectId only when applicable?)

[fm3]

#8912 changes uploads to use datasetId. After that is merged, we could finally go for this issue as described in my previous post