Unassigned tasks display

posted on January 6

I have a feature request or something for an "issue" that's been around for a long time, which is that when users open tasks not assigned to them, some of the logic fires off or otherwise there is some weird behavior. My current situation is users that have submitted requisitions want to check in on them to see their progress, which they can do from the Action History of their submitted tasks (first screenshot). It opens a read-only version of the task, just like if a team task has not yet been assigned or an administrator is viewing it from the instance history.

In the second screenshot you can see a couple places where there is unexpected behavior. The yellow highlight shows fields that were used to set this approver for this step. They do have field values if you look at the variables, and when the assigned user opens the task, but when a different user opens it they blank out (approver is selected from a lookup list and the email is then populated from lookup). Lower down are red highlights showing fields that get populated by default value tokens for the current user. Opening it this way makes this task looks like it's assigned to me even though it isn't. This is causing confusion for users trying to check in on what's going on with their requisitions.

I would like to request that for these cases the form is really read-only. Almost like seeing the "printed" version if I were to open a completed task.

0 0

replied on January 6

Do you have any JavaScript code, or field rules setup that turns those yellow fields blank? Or are those fields blank because that is the work being done at the current task step?

The red fields look like a table with min/max setup to add a row when the form is opened at a new step.

Unfortunately, this is expected behavior. If someone opens a live form, we do expect it to run the logic to render the form in the way you see here. Completed tasks are "hard coded" like you see when printing the form itself. If you fixed it for these users, you would break it for people that do need to work on the form (i.e., hide the fields, etc.)

If the fields have values they will not be overwritten by the default value and won't show up this way on readonly forms. I would just avoid the default value for your case.

0 0

replied on January 6

No JavaScript, but there is some unusual logic. The list of users to select is populated by a lookup seeded by the parameters of a branch field and a "group list" field. This group list field is a calculation and is in a section that is hidden and not saving, so it recalculates on form load (I forget exactly why that was the best option for this form). So it looks like the calculation is not running but the lookup is, wiping out the yellow manager select field. (And that field populates the email field, hence wiping that one out).

The two red fields are just defaulting to the current user, which looks to be active when opening that form even when not assigned; obviously nothing saves, it's just a confusing display thing.

The end result, though, is weird and confusing behavior when looking at the task when it's not assigned to you. If the calculation doesn't run, why do the lookups and default field values?

0 0

replied on January 6

I think the issue is less of the recalculation and more about the current user token. I can't think of a workaround without JS off the top of my head. There is a user task > assigned user token you could use instead of current user but this would likely be problematic depending on how your form is setup.

It sounds like we really just need a "currently_assigned_user" variable instead of just the current user token.

2 0

Discussion

Discussion

Comments 3

Follow-Ups 0

Sign in to reply to this post.