"Owner" privilege required to upload data at project level?

[Simon Doran]

Hi All,

  Does everyone else see the same thing as me (1.8.6.1 and earlier versions)?

  I have users with "Member" access rights, but when they try to upload data (e.g., spreadsheet) at project level via the "Manage Files" dialogue, no "Upload Files" button appears.

  Changing the user's access level to "Owner" rectifies the issue.

  Is this the expected behaviour and if so, why?

  Best wishes,

Simon

[Charlie Moore]

Hi Simon,

I'm aware that this is how it works, but I'm not sure if it's a bug or intended. I've been leaning towards "intended" for a long time because the sorts of things that would be stored in a project's resources would be study-wide things that only a project owner should be defining.

Thanks,

Charlie Moore

[Simon Doran]

Thanks, Charlie.

  I understand the reasoning, but, unfortunately, that doesn't fit something that's a very common use case for us.

  In our institution, what's uploaded at the project top-level tend to be spreadsheets summarising the key clinical variables for all subjects. Arguably, you might say that these should be custom variables and should be filled in on a subject-by-subject basis by someone with member access. However, practically speaking, that's not how the data are supplied. Sites expect to send us a single spreadsheet and they expect it to be uploaded by the same people who upload the rest of the image data.

  What we'd like to be able to do is enable the upload functionality at the project level, but without making the uploader at a site a project owner, because we don't want to give them rights to delete data. Is that possible?

  Best wishes,

Simon

[Rick Herrick]

Unfortunately that’s not possible with resources in the current security model. XNAT doesn’t distinguish between editing a project and editing the stuff secured by the project. The stuff secured by the project is distinct from data in the project that is in turn represented by secured data types.

So. XNAT has secured data types, which have permissions set by XSI type on a per-project/role basis. This means you can ask questions like, “Can a user in the group ProjectId_member edit an instance of xnat:subjectData in project ProjectId?” There are also unsecured data types, where you can’t ask questions like that so you have to be able to trace instances of those unsecured data types to a parent instance of a secure data type and use that as a proxy.

Resources and image scans (semi-sort-of-mostly) are both unsecured data types, meaning you’ve got to look at the parent object to determine permissions. This makes sense in almost all contexts, because there’s little or no difference between the data object and the resources stored in the archive: the data object is basically just metadata about the stored resources that allows XNAT to manage everything. The problem at the project level is there really is a difference between the data object (the project) and the resources stored in the archive, but XNAT just doesn’t deal with that well.

But here’s a possible fix. One of the things we did to work around this very problem was to add the xnat:abstractProjectAsset data type, which supports secured data types that can be stored under a project but have distinct permissions from the project. We did this originally for the data-set and -collection data types for the ML project, since collections of experiments inherently span multiple other objects and can’t be secured by any data types other than the project or the collection itself. You could implement a project-asset data type for your spreadsheets, which has the disadvantage of being a bigger pain than just uploading resources through the file manager but has the advantage of providing control and tracking of that data.

Rick Herrick

Senior Software Developer

rickh...@flywheel.io

------ Original Message ------

From "Simon Doran" <simon...@icr.ac.uk>

To "xnat_discussion" <xnat_di...@googlegroups.com>

Date 12/21/2022 5:47:49 PM

Subject [XNAT Discussion] Re: "Owner" privilege required to upload data at project level?

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/31e6669c-0325-480b-a555-7ba65d400dbfn%40googlegroups.com.

[Joost van Griethuysen]

Sorry for reviving this older discussion, but I have a problem related to this thread.

It's now clear to me that "member"-level users don't have permission to upload files at a project level. However, when using the XNAT API this results in some difficult situations. 

While the API returns a 403 error when I try to create a new resource folder (as expected), trying to upload actual files results in a regular 200 response (with no content in the response). This both applies to the case where I'm uploading new files or updating existing ones using PUT method, as well as when updating existing ones using POST method. In all cases, no file is actually saved/changed (what is expected as the user doesn't have sufficient rights).

The problem here is that I have no way of knowing if my upload was successful. I'd expect a 403 error for individual fileupload as well (seeing as the rights for file upload are still determined at the project level as far as I know). Alternatively, response content specifying that the user does not have sufficient rights would also be welcome (though inferior to the 403 error IMO).

Regards,

Joost van Griethuysen

Op donderdag 22 december 2022 om 18:44:40 UTC+1 schreef Rick Herrick: