Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@regisoc
Copy link
Contributor

@regisoc regisoc commented Sep 24, 2024

Brief summary of changes

This PR checks the user attached projects on top of the dicom_archive_view_allsites permission when trying to access the view details page.

Link(s) to related issue(s)

Resolves #6658

$tarchiveID = intval($_REQUEST['tarchiveID']);
$projectID = self::getProjectFromTarchiveID($tarchiveID);
if (is_null($projectID)) {
return false;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be return true? Otherwise no one will ever be able to see it?

(Maybe a discussion for an imaging meeting?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That means the TarchiveID does not exist in db or is not linked to a project.. ?
I was not sure about this. It is even possible?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can involve @cmadjar

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Point added to next imaging meeting.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm assuming it would mean the TarchiveID is not linked to a project

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Imaging meeting: no one should see it by default.
There should be a specific permission to see the list of "dangling TarchiveIDs" (Tarchive not assigned to any Project). Also might be good to have a front-end page for that.
It will be linked to a new issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created here: #9389

@cmadjar cmadjar self-assigned this Oct 1, 2024
@cmadjar cmadjar added the State: Blocked PR or issue awaiting an external event such as the merge or another PR to proceed label Oct 1, 2024
@christinerogers christinerogers added this to the 27.0.0 milestone Feb 11, 2025
Copy link
Contributor

@christinerogers christinerogers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks to me like it will do the job, provided Dave's change is merged.

@driusan driusan merged commit 957423d into aces:main Feb 17, 2025
19 checks passed
@ridz1208
Copy link
Collaborator

@christinerogers I'm interested in understanding why you would approve this PR 5 minutes after we discussed at the loris meeting that this might create conflicts between the view detail page and the main menu filter of the module and then clearly establishing that it will be brought up with @regisoc upon his return

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

State: Blocked PR or issue awaiting an external event such as the merge or another PR to proceed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[DicomArchive] Add project permissions to Subpage

5 participants