[9.3.4-9.5.0] API issue on PlanningElements access rights

Hello,
I tried the following behavior from 9.3.4 to 9.5.0 and Projeqtor always behaves the same.

my account has almost every access rights on our Projeqtor instance and my profile is not a native one (I have created it by hand in Projeqtor, and its code is also ADM to allow it to perform software updates).
On the gui, I can see everything, without any problem, in particular all the information contained in planningelements.
when trying to access a particular planningelement with the API (eg BASE_URL/PlanningElement/search/refType='Activity'/refId=118 or such as BASE_URL/PlanningElement/88), I get an empty result. This is due to the $listNO (method getAccesRestrictionClause in tool/projeqtor.php:2071 in v9.5.0), as if my user was suddenly not allowed to read some projects.
I would obviously expect to access the same things with the same rights in the gui and from the API.

From the tests I made, I imagine the content of $user->getAccessRights($objectClass, 'NO', $showIdle) is buggy  when objectClass is 'PlanningElement'.
I therefore wrote the very worst workaround ever, adding the following just before this previous line : if ($objectClass == 'PlanningElement') $objectClass = 'Project' ;
It works properly because in my particular case I have no other restriction, but I guess it would be very buggy if I had profile restrictions eg on meetings, milestones or other stuff that ends as a planningelement (ie when the user can see the project but not all of its content).

As a result, as it seems you are about to touch the API (and therefore test it), maybe this access right part needs a little bit of reviewing.

Hope this helps,


 

Hi,

Good point - it's a subject that also interests me very much to better use the API
I have seen in the past (older versions, haven't checked recently) this behaviour, and used the same workaround. I found that the workaround works ok for our use case, but of course it's difficult to generalize.

So if we can find a better way to handle the API access rights on these types of objects, because it would allow us to extend the use of APIs. It's something I'm looking forward to a lot, because it's a great way to give end users more flexibility in generating customized reports for example.

If I can help , for example to provide some use cases that we would like to manage through the API, let me know
 

Hi Babynus,
You’re absolutely right, so many thanks for your answer; I now understand the philosophy.

... so I have just rewinded a little bit to understand why we took such a complicated & useless way and decided to walk through PlanningElements.
When we tried to add Dependencies through the API, we only were able to mention refType and RefId in the data transmitted, but not what I identified as the planningelement ids. As a consequence, the planning was completely wrong.
Is there any magic I’m also missing here? (in other words, how am I supposed to post Dependencies ?)
 

Well, actually, when trying to POST the following to BASE_URL/Dependency :
There is no error in the logs, the API answers  the following (and I swear we did not modified the code of Projeqtor) :
The fields successorId and predecessorId are NULL in the database (which is consistent with the answer of the API) and there is no arrow drawed on the Gantt view (which seems quite normal regarding the data I guess).
Even if recalculating the planning, the NULL values remain NULL.

I can see successor & predecessor correctly set in the activities view (which seems also quite normal regarding the data).

Am I doing something wrong?