Appian Community
Site
Search
Sign In/Register
Site
Search
User
DISCUSS
LEARN
SUCCESS
SUPPORT
Documentation
AppMarket
More
Cancel
I'm looking for ...
State
Not Answered
Replies
10 replies
Subscribers
8 subscribers
Views
3895 views
Users
0 members are here
Share
More
Cancel
Related Discussions
Home
»
Discussions
»
General
How to show the user name in SAIL form who accepts the Same Task form
Piyush Agarwal
over 7 years ago
I want to display the user name in the FORM after he accepts the task form.
I have tried to capture it via task properties but couldn't get through.
Can any one please suggest. Thanks
OriginalPostID-244425
Discussion posts and replies are publicly visible
Parents
0
sikhivahans
over 7 years ago
@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.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Reply
0
sikhivahans
over 7 years ago
@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.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Children
No Data