Hello, I have my scenario in below steps: > I am member

Let us assume you belong to "TaskRun" group and some other group "XYZ" (it is possible to be a member of more groups). When the task is assigned, the tp!assignees property of the task is set. tp!assignees is of user or group type. In this example, it will be set to "Taskrun" group. Now, once you accept it, you "own" that task(and not the whole group "Taskrun" - although you can require that all the users of the assigned group should complete that task to put it in "Complete" state). Hence, the tp!owner property is set to your username. tp!owner is of user type. Also the value of tp!assignees will still not change. It will still be "Taskrun" even after you accept the task. Only the tp!owner changes after accepting the task.
Now, assume you are removed from "Taskrun" group. Naturally, you won't be the owner of that task anymore. The tp!owner will be set to blank again. But value of tp!assignee will still be "Taskrun" group. And since you are no longer in that group, you will get an error the next time when you try to access that task. The system will not try to change the original assignees of the task to any other group. The original assignee will still remain "TaskRun" group. But since you are not member of that group, it will give you error.
I hope this clarifies your question.

Hi Tapas, I don't think you can change task assignment like this, nor you have control to do 'something' when user accepts a task. May be a dumb solution, but how about creating a preliminary task with an 'Accept' button so that when clicked, you can assign the actual task directly to the user(instead of a group) who has accepted the first task in this way ? Then no need to worry about the user being removed from any groups ? I think, it's the severity of your use-case that will require you to roll some dice.

@Tapas - As Goutham specified, we can have a accept task form before your main form. Same situation occured to us and we used similar solution. We had to save the owner of the task in database as it was used for reporting in some other system with sync database.

@tapans An enhancement Goutham's idea here: we could build a reusable component that captures the acceptance and this should be integrated into each and every user input task. This reusable component can consist of acceptance in any format (such as a boolean question with Submit button) and upon interaction, you can trigger a process in the back ground which will modify the task assignees with the current task as context. Here we need to check how the current task behaves if we changes its assignees when we are working on the same task, and if it's okay then there might not be a need to build a separate task. Further it simplifies the job as per my knowledge.

Thank you all for reverting back on this issue. Appreciated.

@chetany, thanks for describing but when we tried, we found that when user is removed from group, tp!owner still shows that user name and it doesn't go out blank.

Adding preliminary task could be one of way but we have very complex workflow designed which doesn't allow any additional step (or additional click) which can overhead for users.

It seems that tp!assignee is having higher precedence than tp!owner, any way to do something here or any other suggestions?

Thanks!