We have uncovered a very interesting issue with our Forms process. Our process is kicked off by Workflow when a document is brought into the repository and the entry id of the document is passed to the Forms instance so the document can be shown with an embedded Web Client. We had an instance that shows in Monitor that it has been assigned to a user since June of 2020. For whatever the reason they asked about the document today so we did some digging since they reported it wasn't showing in the Forms Inbox. The Workload report did not show it assigned to the user that Monitor showed it was assigned to. After assigning it to myself and then back to the user it showed for the user correctly. I have since found a handful of such cases. How would this happen? Is there a faster way to correct this than manually checking? We are using Forms 10.4.4.444.
Question
Question
Forms Tasks Not Showing for Users Even Though Monitor Says They Are Assigned
Answer
We have confirmed the bug that workload report did not show tasks assigned to removed users, and we will fix it in next release, sorry for the inconvenience.
The SQL query to find all tasks assigned to removed users could be:
SELECT wr.resume_id, us.username FROM [cf_bp_worker_instnc_to_resume] wr INNER JOIN [cf_user_snapshot] us on wr.owner_snapshot_id = us.id WHERE us.user_id is NULL
When users are removed from system security they are removed from [cf_users] table but the info in [cf_user_snapshot] is still kept so you could still see it on monitor page. And if you add this user back and synchronize on forms, the tasks are still assigned to that user.
So if you would like to bulk reassign those tasks to a different user, you could try script like this:
UPDATE [cf_bp_worker_instnc_to_resume] SET owner_snapshot_id = NEW_USER_SNAPSHOT_ID WHERE resume_id in ( SELECT wr.resume_id FROM [cf_bp_worker_instnc_to_resume] wr INNER JOIN [cf_user_snapshot] us on wr.owner_snapshot_id = us.id WHERE us.user_id is NULL)
Replies
We are still working on narrowing down this issue. From what we can tell, it appears that if the user does not show in the Administration -> System Security page, but is assigned a task, it does not show the user as having a task in the Workload report, but does show in Monitor.
I am curious why when a user has their license removed that the system does not suspend all tasks for that user?
I just ran a test scenario to see if my assumption was correct and it looks like it is.
Steps to replicate:
- Added a user account in LFDS, assigned it a license, and added it to a group that has permissions in Forms.
- On the Forms Administration -> System Security page, Synchronized Users.
- Created a test Forms process with 1 user task and assigned the task to the new user account.
- Submitted the form and verified that the task was assigned to the new user account in Monitor and the Workload report.
- Unlicensed the user account in LFDS.
- Synchronized Users in Forms. The user account in Forms now shows as invalid.
- The task still shows as being assigned to the user account that is no longer licensed in Monitor and the Workload report.
- Removed the Invalid user account in Forms on the System Security page.
- The task still shows as being assigned to the user account in Monitor, but not the Workload report.
Because of this a user task can stay assigned to a user account that is no longer licensed and no one would know with out going through all the active tasks, which in our case is almost 24,000 tasks.
It would be nice if when a user account becomes invalid that Forms looks for all tasks currently assigned to that account and suspends them so the Administrator knows and can correct them.
Until that is a feature, does anyone have a SQL query to find all tasks assigned to users that are no longer in the cf_users table in the Forms database?
Good catch. It sounds like what we run into is most likely a different issue. The (rare) issue we have isn't with users who are removed; it is actually users who are still very much active and licensed.
The tasks will show up as assigned to them in monitoring and such, but they just won't show up in their Inbox for some reason. Again, this is extremely rare and so I haven't seen it happen for many months.
Jason, good to know you might be experiencing a different issue. To be honest, we might as well. What I posted above was something we stumbled on while trying to find a reason. I was able to replicate it, but we honestly don't know if that is the cause of we experiencing.
We have confirmed the bug that workload report did not show tasks assigned to removed users, and we will fix it in next release, sorry for the inconvenience.
The SQL query to find all tasks assigned to removed users could be:
SELECT wr.resume_id, us.username FROM [cf_bp_worker_instnc_to_resume] wr INNER JOIN [cf_user_snapshot] us on wr.owner_snapshot_id = us.id WHERE us.user_id is NULL
When users are removed from system security they are removed from [cf_users] table but the info in [cf_user_snapshot] is still kept so you could still see it on monitor page. And if you add this user back and synchronize on forms, the tasks are still assigned to that user.
So if you would like to bulk reassign those tasks to a different user, you could try script like this:
UPDATE [cf_bp_worker_instnc_to_resume] SET owner_snapshot_id = NEW_USER_SNAPSHOT_ID WHERE resume_id in ( SELECT wr.resume_id FROM [cf_bp_worker_instnc_to_resume] wr INNER JOIN [cf_user_snapshot] us on wr.owner_snapshot_id = us.id WHERE us.user_id is NULL)
Glad to hear it and thank you for the scripts. When you say that it will be fixed in the next release, what does "fixed" mean? Will the tasks become suspended? The tasks staying assigned to users that become unlicensed is really the bigger issue for us.
I meant the bug that workload report did not show tasks assigned to removed users.
As for the request to make task suspended when user become unlicensed, that would break the function to keep task valid when user with same sid was added back, which is a known scenario reported in some support cases.
What we have thought about: do not allow to delete inactive user if he has assigned tasks; or just show info on delete dialog that user has assigned task and let admin confirm it. Do you think if this could help in your case?
The main issue for us is knowing if a non licensed user still has tasks assigned. Since the tasks don't suspend or somehow indicate there is an issue, those tasks could sit with the unlicensed users for a long time before anyone realizes it. We have over 2,000 users processing Forms tasks and users come and go quite frequently, so this is a huge issue for us.
Fixing the bug of the tasks not showing in the Workload report will actually make this harder for us to hunt down without another option.
Thanks for the feedback, I have added it to our feature request list.
As for the bug, we will mark the user as "invalid" when shown on workload report so admin could find it obvious and reassign it if needed.
We've encountered the same thing. It's been rare enough that I haven't worried about it too much, but it definitely does happen to where it says it is assigned, but when we have the user log into forms it definitely isn't showing in their Inbox tasks.
The solution has been as you described, assigning it to ourselves then back to the user and so far I haven't really found any other way to handle the issue.
What I usually find myself doing is periodically checking for tasks that have been sitting for an unusually long period then reassigning them back to the original team/user, but it would be nice to have a better option or if the underlying issue was resolved.
I guess our problem is that we have 22,000+ active tasks in this one process. While focusing in on those that have been sitting for awhile will cut that down, it's still a lot to manually be checking on.
Since this is a recurring issue though, it sounds like a possible bug within Forms.
I agree, we also have a substantial amount of activity and even looking at "old" tasks it can be really hard to tell if something is sitting for a legitimate reason or if the user really can't see it in their inbox.
In my experience it has been extremely rare, so it hasn't caused us too many problems, but it does happen and when you have a lot of instances/tasks even "rare" can add up to be a noticeable amount.
I imagine it has to be some sort of bug where the task is generated and assigned but whatever step connects that to the user's inbox doesn't get completed.
I have opened a support case with Laserfiche through our SP. Hopefully we can narrow it down.
@████████,
If you are able to currently replicate it, would you mind opening a support case as well? It would give Laserfiche Support more information to narrow it down with.
@████████
I'll keep an eye out. I've never been able to reproduce it intentionally, but next time it comes up I'll try to get support involved so they can take a look.