How to give project_user (role) user access to write in projects tasks where he/she is the PM of the parent project?

skendy
Tera Expert

Hi,

I have been thinking how to let users with project_user role to have write acl on the table pm_project_task ONLY if he is the project_manager (field) of the parent project (pm_project).

I grant write to the role with a condition where (dot walking) .u_ref_proj.project_manager is (dynamic) me, but then all project tasks fields become Read Only.

u_ref_proj is a project task field which references to project table.

I have been trying to add the following script (suggested by other in the community) instead of the control but nothing changes:

It is weird because I applied the same script for omitting the New button (thanks to Anurag) from the list and it worked (changing the true/false for the answer)...

var utente=gs.getUserID();

if (parent.project_manager==utente)             //since we have a relationship/related list between the two tables

      answer=true;

else

      answer=false;

I would appreciate any comment!

Thanks,

Skender

1 ACCEPTED SOLUTION

just write the code that when a new task is added , the project number is filled in u_ref_proj.


And on the projet form use the "-> parent" related list.


This will fix all your troubles.


-Anurag

View solution in original post

19 REPLIES 19

In order to have that field autopopulated,


I created this relationship (I applied the same code as for custom tables in relation with pm_project), but it is NOT working:



project_task_relation_project.png


amullendarby
ServiceNow Employee
ServiceNow Employee

Hi Skender, I had a customer do this before using the is (dynamic) me operator/value combo on pm_project and pm_project_task. It sounds like it is similar to what you tried but instead of using parent on pm_project_task, they used top_task so that you weren't just restricting the parent. They looked something like this



condition on pm_project write rule: project_manager is (dynamic) me


condition on pm_project_task write rule: top_task.project_manager is (dynamic) me



Then they had two more acl rules that gave a custom role (project_admin) write access to both tables so that someone could modify all projects and tasks. Let me know if that doesn't work and I can do some testing when I get a minute.


Here the problem is more complicated.


I have several field write access (when project_manager depending from the logged in user) because the two roles:


- project_manager


- project_user


both work on the project form, but they write on different fields (security constraints from the customer).



I tried the second condition on pm_project_task (as a script because I cannot choose from the menu Condition) but when I log-in as a project_user, even if I am the project manager (field) of the project, I still cannot write:



var utente=gs.getUserID();


if (top_task.project_manager==utente)     //does top_task refers to pm_project table?


      answer=true;


else


      answer=false;




Anyway thanks,


Skender


top-task is a field of planned_task table



in the ACL instead of the condition( .u_ref_proj.project_manager is (dynamic) me) use the script part and write the script like this


var utente=gs.getUserID();


if (current.u_ref_proj.project_manager==utente)     //does top_task refers to pm_project table?


      answer=true;


else


      answer=false;


-Anurag

kellykaufmann
Mega Guru

Can I open dialogue on this request from a process perspective?


Are you looking to make it so NOBODY except the PM can create & edit project tasks?



I know if you have experience with MS Project that you may want to do this in SN because of fear of people 'messing up' the project schedule (I always had my MS Project schedule under lockdown), as that was really easy to happen in MS Project. HOWEVER, I'd like to note that you are eliminating one of the big selling points of using Project in SN - it eliminates the burdensome task of the PM to have to ask everyone for their updates & then manually make the updates, and secondly that the PM has complete history of every change made (and can set up notifications so they know when a team member has marked their task as complete etc), and third that if anything does get out-of-whack because of an 'automatic' style schedule that triggered a domino effect of date changes - that you can trace it back to that one change & set it back.



On the first point, all of SN works by having people assigned to specific items - Incidents, Service Catalog tasks, project tasks, etc. - and puts the impetus on the individual to keep those things updated. Users can leverage their homepage to keep track of all their tasks & make updates from there, leverages VTB's to organize their tasks & simply drag the task to another column to easily update the state of that task.



Also, if the PM is afraid of the domino effect of marking a task complete early & it updating the dates of all the subsequent tasks - just make a project's schedule type to manual, and this won't happen.



So personally, I suggest talking w/the requester of this change through the fear of people updating their own tasks. Talk about how the SN setup is different from MS Project & can save a lot of time of the PM. If you need any of us to talk through this with your team, myself and I'm sure others are more than happy to talk through this. But this is something they may not understand in SN's functionality.