Permission issue while opening the task on production and it is working of other users belongs to same group

You need to check iv_i_assignadhoctaskwithdocument.  It's not about the rule, but about the rule that it calls, and the rule it calls, and the rule it calls.  Appian alerts like to give you the full rule hierarchy.  You definitely have an applyComonents() on line 113 in one of the rules in the chain.  And applyComponents is notorious for being very difficult to apply null safety to.

Once you find it, you will need to investigate the inputs to try to figure out why one of them would return null.  Try running that rule by itself with different inputs until you're able to reproduce the error.  Now your bug is how in the world the inputs from production got that way.

thanks for your quick reply I got the apply component is being called exactly at row number 113 . You mean to say that this is returning null

 rows: a!applyComponents(
                function: rule!iv_gr_object(
                  objectInstances: local!allObjectInstances,
                  deletedObjectInstances: ri!deletedObjectInstances,
                  index: _,
                  readOnly: ri!isReadOnly,
                  refreshedObjectInstances: local!refreshedObjectInstances,
                  locationEntity: true(),
                  departmentId: local!departmentId
                ),
                array: if(
                  or(
                    rule!APN_isEmpty(
                      local!allObjectInstances
                    ),
                    count(
                      local!allObjectInstances
                    ) < 1
                  ),
                  {},
                  1 + enumerate(
                    count(
                      local!allObjectInstances
                    )
                  )
                )/*arrayVariable: local!objectInstancesToken*/
               
              ),

No, one of the parameters of the applyComponents() is null.  applyComponents breaks down completely when it receives a null in place of a list.  Whatever generates the list that's passed into your applyComponents at least sometimes returns 0 rows, and Appian frequently reinterprets zero rows as a null of type Text.

Look at the if().  If the or() returns true, it returns {}.  That's it!  The or part is sort of redundant too, because APN_isEmpty I think already checks for count less than 1.  So, if the local!allObjectInstances is empty or null, it breaks.  Only when there's values in local!allObjectInstances does it ever work without error.

So, whoever designed it really, really tried to add valid null safety, but unfortunately it doesn't work with applyComponents.  When you transfer that to an a!forEach that does the same thing, the null safety will work.  Apply the null safety in the expression parameter of the a!forEach.  If it gets null or empty list, it just returns null or empty list.

Now, part two is going to be figuring out why local!allObjectInstances is empty in this case, and whether it should be.  If it really should, you're done.  Otherwise, you have an additional mystery to solve.

Thanks a lot David. I checked that already local!allObjectInstances has value in it . I" am now confused with "Insufficient permission" given in the logs . So you means to say if null is passed to Applycomponent it may give "Insufficient permission" error.

poojaprakashs763 said:

PrivilegeException[null=>null]

That's the entire basis for this argument.

Now, given that there is a value, we have to investigate further what it is about that value.

Perhaps whoever (if the value is a person) doesn't have any permissions.  Or is it a DB pointer that doesn't really point to a user at all?