Write ACL on the task table

[Alon Grod]

How can I write advance write acl on the task table that only if the current login user = assigned to, he will be able to edit the task(RITM, INC etc)

[Alon Grod]

@Sandeep Rajput 
1. the user is not admin
2. even there was a write acl before, when I create a new write acl it looks on the newest one right?

[Sandeep Rajput]

@Alon Grod If more than one ACLs are present they all are evaluated until one of them grants the access or all of them fail.

Deactivate the other write ACls by unchecking the Active checkbox on those write ACLs and keep only the recent one Active. After this change only the task assignee or the admin user would be able to edit the task.

[Jim Coyne]

Instead of just telling you how to create one as many people have just jumped in here and done, I would first ask you:

1. WHY do you want to do this?
2. Are you sure you want to do this?
3. Why are you specifically asking for a "advance write acl"???
4. Do you understand the implications of what you are asking/have been asked to do?

As others have shown, an "advanced" Access Control is NOT required to do what you want.  And as @pablo_itguy_pl has mentioned there may be a HUGE impact if you do this.  I say "may", because, as you've seen, adding one may not do exactly what you want because there a a ton of other Access Controls written on extended tables that will allow writing to those records regardless of your new rule on Task.

And from the picture you sent, you created the Access Control on the Incident table and NOT Task.  That could be because you were just doing as someone suggested but had not fully understood.  And your "its not working" responses are not very helpful.  I'm guessing "it's not working" because you created the rule on Incident and not Task.  What's not working?  What is happening?  Or NOT happening?

Access Controls are very important and tricky to create and maintain.  That's why a separate Role is required to create/edit them.  Not everyone should be messing with them.  One needs to fully understand how Access Controls work in order to create them properly.  And need to understand the REAL client requirements.  Oh, and by the way, TNT: The Customer is NOT Always Right.

[Alon Grod]

@Jim Coyne i have a requirement that only if the current login user == assigned to, he will be able to edit the incident. I tried to use onLoad client script but only some of the fields become read only, so i was suggested to use write ACL. Even when I made the same ACL on the task table it didnt make the fields read only when the condition is not met.

[Jim Coyne]

OK, now we are getting somewhere.  Your original post mentioned creating the ACL on the "task table" as well as "will be able to edit the task(RITM, INC etc)".  So now it seems like we can concentrate on the Incident table only.

Out of the box, there are a number of Access Controls that give write access to the record to others, such as users with the "itil" or "sn_incident_write" Roles or the user who created the Incident or the user the Incident is opened for (basically to add comments for the last two cases).

Now, all that being said, there's still a problem with what you want to do: what happens if you want to re-assign the Incident?  Will not be able to be done except for users with the "admin" Role.  If you restrict the write access too tight, you are going to have yourself a real administrative mess.  At the very least, users in the same group as the Assignment group should be allowed to edit the Incident.  But more so, users with a certain Role should be allowed.

I'm just guessing, but it seems like what is being done is to avoid accidental user errors and not real-world requirements.  Seems more like a training issue more than anything else.