Hello,
Unless I'm mistaken I think there may be an issue with API handling of "special" classes, where access rights are improperly handled.
As an example, I have been doing some testing using the 'Work' class.
I am using curl, but the request i'm sending out is something like this :
'my-url/api/work/search/idProject=160'.
User which is used for the API connection has a project leader profile.
=> Result is that I can fetch work from projects which PL is NOT affected to, and not from project he IS affected to...
Bottom line: when doing a GET for class Work, we end up checking access rights in UserMain::getAccessRights(), and in particular via the following line:
$menu=$obj->getMenuClass ();
Since there is no specific menu for Work class, there is no access right definition for menuWork in the 'accessright' table, and I end up with a query to DB looking like this:
select * from work where idProject=460 and
(work.idProject not in (456, 1, 448, 449, 451, 464, 450, 452, 453, 455) // <-- these are the projects the PL is affected to
or work.idProject is null )
and (work.idProject not in (0) or work.idProject is null or (work.idResource='559') );
I've simply overridden
getMenuClass() in model/custom/Work.php for a quick test, it seems to do the trick:
public function getMenuClass() {
return "menuActivity";
}
I'm not sure what's the best way to properly fix, but hope it helps!
Note: I think the same applies to class Assignment, among others.
Cheers,
caccia