[imaging_uploader] Site&Project check with config setting and permission #9533

ridz1208 · 2025-01-15T20:51:33Z

Brief summary of changes

These changes offer a backwards compatible way of adding Site and Project permissions to the imaging_uploader module.

Since the imaging_uploader may contain uploads which fail validation (for whatever reason) and are thus not associated to a sessionID in the mri_upload table, the files are not technically associated with a site and project. In the current implementation all users with access to the module have access to all uploads which is problematic for institutional instances like CBIG. The changes here include a config setting to enable/disable the use of site/project checking (disabled is the status quo) but also include a permission which can give a user access to only their site's/project's data + any file with no sessionID and thus no site or project. Which should cover all use cases past and future

Note: To all the config setting haters (@driusan) it was my impression from the last meeting we had that there is no near future in which all projects revert to forcing a sessionID in the imaging modules or otherwise fail the insert so I think a config setting is warranted here for other instances to not have overrides for 10+ years

Testing instructions (if applicable)

Set the config setting to false/off/no...
the module should have regular behaviour unaffected by this PR
Set the config setting to true and test with a regular user
make sure user only has access to their site and project uploads AND uploads they make themselves (even if the uploads fail validation and do not have a site and project)
give the user the imaging_uploader_nosessionids permission
make sure the user now has access to their site and project uploads AND uploads they make themselves AND any other upload with no associated site and project

voila

Link(s) to related issue(s)

Resolves # (Reference the issue this fixes, if any.)

ridz1208 · 2025-01-15T20:52:15Z

@cmadjar @nicolasbrossard

Assigning both of you to check for redflags.

nicolasbrossard · 2025-01-17T19:27:52Z

Why not have a permission that allows you to have access to ALL uploads (i.e even uploads not from the user's site)? With your new permission definitions, I don't think there can be an imaging uploader super-user when useSiteProjectPermissions is ON.

ridz1208 · 2025-01-18T01:01:24Z

@nicolasbrossard I'm not sure if you are suggesting that functionality on top of what I'm adding or instead of but I'll try to answer it either way.

So yes, you are correct but my goal on CBIG is not to have anyone be superuser in fact I shy away from giving anyone any superuser or all site permissions at all. I think it boils down to the following.

If you are a regular Joe Schmoe and ur using the uploader, you can see things uploaded at your site, for your project AND things you uploaded yourself!
if you are Joe Schmoe's boss, you probably see things uploaded at all your sites and all your projects AND things you uploaded yourself!
If you draw the short stick and you have to fix all of Joe Schmoe's mistakes along with Mickey Mouse's, Donald Duck's, Bugs Bunny's and Fred Flinstone's mistakes. You lucky ducky get imaging_uploader_nosessionids to see all problematic uploads AND you see your own and you see all your sites and projects...

I don't see the all sites usecase anywhere, I think even case #3 (closest to superuser) you would just get the sites and projects you need assigned to you instead of getting some sort of magic all sites permissions because ultimately if you need to debug anything you will also need imaging_browser all sites, access_all_profile, issue tracker all site and a bunch of other all sites... you might as well get all the sites?

Plus, it doesnt even make sense anymore to have all sites because it either needs to include all projects or we need to make a separate all projects permission or an all sites and all projects...

kongtiaowang · 2025-01-22T14:46:09Z

Sourcing raisinbread/RB_files/RB_ConfigSettings.sql
ERROR 1064 (42000) at line 123: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'INTO ConfigSettings (Name, Description, Visible, AllowMultiple, DataType, Parent' at line 1

ridz1208 · 2025-02-19T19:47:24Z

@nicolasbrossard @cmadjar One issue remains here, can someone upload a scan for a candidate not at their site/project ?

driusan · 2025-02-24T18:12:53Z

Two issues--what Rida said, and it has conflicts and can't be merged

nicolasbrossard · 2025-02-24T18:58:30Z

@ridz1208 @driusan @cmadjar I'll upload a scan for a candidate not at their site/project once this PR has been rebased.

nicolasbrossard · 2025-02-26T15:32:34Z

All cases were tested on my VM and I could not find a bug. I did fid minor typos (see review). I could not test whether or not a user can upload a scan to a session that is not associated to either a project or a site he's not allowed to use since the imaging uploader was broken at the time of testing, so this test is still pending.

nicolasbrossard · 2025-01-17T20:16:12Z

modules/imaging_uploader/php/imaging_uploader.class.inc

+            $projectString = implode("','", $user->getProjectIDs());
+            $username      = $user->getUsername();
+
+            if ($user->hasPermission('imaging_uploader_nosessionid')) {


Nitpicking here, but the if/else could be rewritten as:

$where = " WHERE (s.CenterID IN ('$centerString') AND s.ProjectID IN ('$projectString') ) OR mu.UploadedBy='$username'"; if ($user->hasPermission('imaging_uploader_nosessionid')) { $where .= " OR s.CenterID IS NULL OR s.ProjectID IS NULL"; }

nicolasbrossard · 2025-01-17T20:22:14Z

modules/imaging_uploader/test/TestPlan.md

+3. Set the `useSiteProjectPermissions` (Use Site Project Permissions) Configuration to NO and make sure your
+   user does NOT have the `imaging_uploader_nosessionid` permission (do not use superuser)
+   [Manual Testing]
+4. Check that when accessing the Imaging Uploader page, the 'Browse' tab displays all the uploads done for all users.


Step 4: if the user does not have imaging_uploader_nosessionid, then he/she should not see ALL uploads done for all users (only those that have a session ID).

@nicolasbrossard IF the useImagingSiteProjectPermissions I think the imaging_uploader_nosessionid should not block you from seeing ALL scans. thats done for backwards compatibility (or at least it should be) i.e. projects not expecting a sessionID to always be defined leave the configuration off and are unaffected by the new permissions.

Is this not the functionality you noticed?

You are right: if useImagingSiteProjectPermissionsis not No, then you see all scans. Disregard my last comment.

nicolasbrossard · 2025-02-26T14:00:45Z

raisinbread/RB_files/RB_ConfigSettings.sql

 INSERT INTO `ConfigSettings` (`ID`, `Name`, `Description`, `Visible`, `AllowMultiple`, `DataType`, `Parent`, `Label`, `OrderNumber`) VALUES (130,'DownloadPath','Where files are downloaded',1,0,'text',26,'Downloads',4);
 INSERT INTO `ConfigSettings` (`ID`, `Name`, `Description`, `Visible`, `AllowMultiple`, `DataType`, `Parent`, `Label`, `OrderNumber`) VALUES (131,'EEGUploadIncomingPath', 'Path to the upload directory for incoming EEG studies', 1, 0, 'text', 26, 'EEG Incoming Directory', 15);
 INSERT INTO `ConfigSettings` (`ID`, `Name`, `Description`, `Visible`, `AllowMultiple`, `DataType`, `Parent`, `Label`, `OrderNumber`) VALUES (132,'useDoB','Use DoB (Date of Birth)',1,0,'boolean',1,'Use DoB',12);
+INSERT INTO `ConfigSettings` (`ID`, `Name`, `Description`, `Visible`, `AllowMultiple`, `DataType`, `Parent`, `Label`, `OrderNumber`) VALUES (133,'useImagingSiteProjectPermissions','Restricts access to dat based on both sites and project. Allows access to data with no session affiliated using a special permission only',1,0,'boolean',50,'Use Advanced Site Project Permissions',5);


Typo:
access to dat => access to data

I'll fix it with the rebase thanks

nicolasbrossard · 2025-02-26T20:22:41Z

I successfully uploaded a scan for a project/site that I am not allowed to use. Not sure this is a desirable feature...

nicolasbrossard · 2025-02-27T00:23:56Z

modules/imaging_uploader/php/imaging_uploader.class.inc

                            );
                    }
+                    // Basic fields have been validated, check user permisions
+                    $session = \TimePoint::singleton($candidate['SessionID']);


This is not going to work: TimePoint::singleton takes a SessionID as argument.

nicolasbrossard · 2025-02-27T01:57:17Z

SQL/0000-00-02-Permission.sql

 ) ENGINE=InnoDB DEFAULT CHARSET=utf8;


+<<<<<<< HEAD


Rebasing too fast maybe? :)

AAAAAAAAAAAAAAAAA

nicolasbrossard · 2025-02-27T13:31:46Z

With useImagingSiteProjectPermissions turned on and as a user that only has Imaging Uploader: View/Upload Imaging Scans - Own Sites, I cannot upload a scan to a site/project I am not affiliated with. When useImagingSiteProjectPermissions is turned off though, I can. I am assuming that's the intended behaviour so all is good.

ridz1208 · 2025-02-27T13:55:37Z

@nicolasbrossard yes intended behaviour (I tried to clarify that in the test plan) but basically the configuration option is meant to switch beteeen the current way the module works (everyone can do everything) and the institutional way where people can only operate within their sites and projects

stale

nicolasbrossard · 2025-02-28T18:21:41Z

modules/imaging_uploader/README.md

-The imaging uploader module uses one permission called `imaging_uploader` that 
-is necessary to have access to the module and gives the user the ability to 
-upload and browse all scans uploaded to the database.
+*In the interest of backwards compatibility, permission behaviour varies slightly 


Backward compatibility (not backward_s_). There are also other occurrences.

nicolasbrossard · 2025-02-28T18:23:29Z

modules/imaging_uploader/README.md

+
+Any of the following permissions grants access to the module.
+
+`imaging_uploader_allsites`: 


I think it would be a good idea to mention somewhere that you always have access to the scans you uploaded.

its in the test plan... not sure where itwould fit in the readme? any sugestions ?

I would put the comment at the very end of the Module Permission section.

Realined with dicom archive

ridz1208 assigned nicolasbrossard and cmadjar Jan 15, 2025

ridz1208 requested review from cmadjar and nicolasbrossard January 15, 2025 20:52

ridz1208 unassigned cmadjar and nicolasbrossard Jan 15, 2025

ridz1208 force-pushed the imaging_uploader_projectsite branch from 31af8bf to 71343b5 Compare January 16, 2025 04:34

CamilleBeau assigned ridz1208 Jan 20, 2025

ridz1208 added the State: Blocked PR or issue awaiting an external event such as the merge or another PR to proceed label Feb 5, 2025

ridz1208 force-pushed the imaging_uploader_projectsite branch 4 times, most recently from 2c008dd to 5bc7fa1 Compare February 5, 2025 20:02

ridz1208 added this to the 27.0.0 milestone Feb 13, 2025

ridz1208 force-pushed the imaging_uploader_projectsite branch from 5bc7fa1 to a346d7c Compare February 19, 2025 17:07

ridz1208 removed their assignment Feb 19, 2025

nicolasbrossard requested changes Feb 26, 2025

View reviewed changes

ridz1208 force-pushed the imaging_uploader_projectsite branch from a346d7c to ea174fa Compare February 26, 2025 19:57

nicolasbrossard requested changes Feb 27, 2025

View reviewed changes

ridz1208 force-pushed the imaging_uploader_projectsite branch 3 times, most recently from f602eb4 to 5ea200a Compare February 27, 2025 01:53

ridz1208 requested a review from nicolasbrossard February 27, 2025 01:53

ridz1208 removed the State: Blocked PR or issue awaiting an external event such as the merge or another PR to proceed label Feb 27, 2025

nicolasbrossard requested changes Feb 27, 2025

View reviewed changes

ridz1208 force-pushed the imaging_uploader_projectsite branch 2 times, most recently from 151db25 to 1a4805f Compare February 27, 2025 02:22

nicolasbrossard previously approved these changes Feb 27, 2025

View reviewed changes

ridz1208 force-pushed the imaging_uploader_projectsite branch 4 times, most recently from dbcf7e8 to 1c0899c Compare February 27, 2025 20:33

ridz1208 assigned GeorgeMurad Feb 28, 2025

nicolasbrossard requested changes Feb 28, 2025

View reviewed changes

[imaging_uploader] Site&Project check with confgi setting and permission

1132d6a

Realined with dicom archive

ridz1208 force-pushed the imaging_uploader_projectsite branch from 1c0899c to e182e80 Compare March 11, 2025 14:57

Upload permission

cfda90b

ridz1208 force-pushed the imaging_uploader_projectsite branch from e182e80 to cfda90b Compare March 11, 2025 14:59

nicolasbrossard approved these changes Mar 11, 2025

View reviewed changes

driusan merged commit 8071ed9 into aces:main Mar 11, 2025
19 checks passed


		Any of the following permissions grants access to the module.

		`imaging_uploader_allsites`:

[imaging_uploader] Site&Project check with config setting and permission #9533

[imaging_uploader] Site&Project check with config setting and permission #9533

Uh oh!

Conversation

ridz1208 commented Jan 15, 2025

Brief summary of changes

Testing instructions (if applicable)

Link(s) to related issue(s)

Uh oh!

ridz1208 commented Jan 15, 2025

Uh oh!

nicolasbrossard commented Jan 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ridz1208 commented Jan 18, 2025

Uh oh!

kongtiaowang commented Jan 22, 2025

Uh oh!

ridz1208 commented Feb 19, 2025

Uh oh!

driusan commented Feb 24, 2025

Uh oh!

nicolasbrossard commented Feb 24, 2025

Uh oh!

nicolasbrossard commented Feb 26, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nicolasbrossard commented Feb 26, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nicolasbrossard commented Feb 27, 2025

Uh oh!

ridz1208 commented Feb 27, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

nicolasbrossard commented Jan 17, 2025 •

edited

Loading