[new_profile] Make list of available projects user dependent

[ridz1208]

Brief summary of changes

It seems like until this PR any user, regardless of their projects, could create participants for any other project. This is very problematic on the institutional LORIS instances like CBIG and BHI.

Currently submitted to CBIG as an override

[kongtiaowang]

To fix the test, option 1: return "$projList[$projectID] = $projectName"
option 2: change "1" to "Pumpernickel" in modules/new_profile/test/new_profileTest.php:94

[ridz1208]

@kongtiaowang thanks, I'll check it out once I get confirmation that we are moving ahead with this

[ridz1208]

@driusan as you pointed out this is merely changing the front end options for projects and not preventing the actual creation of participants for other projects.

Problem is, changing the validation changes the API and I'm not 100% sure if that should be done at this stage? is it a bugfix or a change of behaviour ?

[driusan]

I think there's two separate related questions:

1. Can a user see other projects via the API?
2. Can a user create candidates for other projects via the API?

It's debateable whether changing 1 would be a bug or a change in behaviour. Point 2, I think, is definitely a bug if it's not currently returning a 403 error.

[ridz1208]

@driusan

1. projects GET gets all projects, not only the user's
2. yes the API allows creation of candidates at projects that user is not affiliated with

[ridz1208]

@driusan

Loris Api Candidates
 ✘ Post candidates candid [692.80 ms]
   │
   │ Failed asserting that 403 matches expected 400.
   │
   │ /home/runner/work/Loris/Loris/raisinbread/test/api/LorisApiCandidatesTest.php:291

This test was relying on the Project instantiation to fail to return a 400 is Project='' in the JSON object. the problem is that I added my check for the project affiliation ahead of that so it returns 403 now. Is it a bad idea for me to move it below the project instantiation to catch the 400 first and then check for user affiliation?