How to show the user name in SAIL form who accepts the Same Task form

@piyusha I would say it depends. So there could be two cases here afaik:

1. Multiple task assignees
Let's say a task is assigned to multiple assignees (array of Users or array of Groups or a combination of both) and one of the assignee(a User) has opened the task but hasn't accepted it. Then it might not be useful if you start showing the logged in user as owner of the task because a logged in user becomes Owner only when the task is accpeted by him/her. It might be worth depending on task status and then show the logged in user. That is, check if the task status is Accepted, and then start showing the logged in user as Owner, else surface a null value till the task is Accepted.

2. Where the user is the task assignee
Here it makes sense to go ahead with the logged in user and depending on analytics is a redudnat job. (As a side note, this logic defies, if the user has capability to reassign task and if user assigns task to more than one(or if the task is assigned to multiple assignees as part of Support from a Task Report) and this won't be valid and option 1 is the best bet.)

task_assignee_owner might not be an option because it displays the task assignee information(until the task is accepted) which I would call it as redudant because it's already available on the top of the task, that is, near the Accept button when you open the Task and also in the Task list above a Task name and moreover what it displays is not a Owner until and unless the task status turns to Accepted.

Let us know if your question is about querying the task properties and we are more than happy to assist.

@piyusha I would say it depends. So there could be two cases here afaik:

1. Multiple task assignees
Let's say a task is assigned to multiple assignees (array of Users or array of Groups or a combination of both) and one of the assignee(a User) has opened the task but hasn't accepted it. Then it might not be useful if you start showing the logged in user as owner of the task because a logged in user becomes Owner only when the task is accpeted by him/her. It might be worth depending on task status and then show the logged in user. That is, check if the task status is Accepted, and then start showing the logged in user as Owner, else surface a null value till the task is Accepted.

2. Where the user is the task assignee
Here it makes sense to go ahead with the logged in user and depending on analytics is a redudnat job. (As a side note, this logic defies, if the user has capability to reassign task and if user assigns task to more than one(or if the task is assigned to multiple assignees as part of Support from a Task Report) and this won't be valid and option 1 is the best bet.)

task_assignee_owner might not be an option because it displays the task assignee information(until the task is accepted) which I would call it as redudant because it's already available on the top of the task, that is, near the Accept button when you open the Task and also in the Task list above a Task name and moreover what it displays is not a Owner until and unless the task status turns to Accepted.

Let us know if your question is about querying the task properties and we are more than happy to assist.