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... :blink:

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