Error message around removing someone from a board who does not have permissions

[Adrian Simpkins]

Hi All,

Some of my full Users keep seeing an error message appear around uncaught attempt to remove user from card they are not member of. This appears when they are assigning a request across to another team - however the requests are not at the stage in the BPM where it would look to auto remove a request from the board, so I am trying to understand why it is stating this error, when the request is not yet at a point where it would be removed from the escalation board. As an example the request below was transferred from one team to another, but at the point of the analyst transferring the request to the other team the error comes up. The request has been auto added to our escalation board just through the set criteria in the SLA being met. Image below shows the error:

Many thanks

The request was added to the escalation board on the 6th, and the analyst made the transfer on the 9th as shown below.

There was a problem with our SLA around the time this request was raised where some of the auto escalation configuration was removed - this was reinstated to the correct configuration on the 9th / 10th January so this request was raised after that issue.

Any ideas around how to resolve this please?

Many thanks as always

 

[James Ainsworth]

Do these users have the Board BPM Access role? 

[Adrian Simpkins]

Hi James

Just double checked and the affected users both have the Board BPM Access, and Board User roles. However the board that these requests write to is not open to everyone - just the managers of teams. The error seems to be appearing just for a handful of Users - I think about 4 in total. Others may be getting the error and just not reporting it

Many thanks

[David Hall]

Hi @Adrian Simpkins

I've been unable to replicate this issue so far and from a review of the code there are checks to try to ensure that only when the owner has changed does it try to update the member on a request board card.

From the screenshot however I notice that there are multiple errors shown from trying to attempt to assign the request to the existing team/analyst.  In my local tests we prevent the assign button being active in the browser if the selected team or owner are not different and the error is only shown when we fall back to server checks.  I guess my thought is that the board error is a knock on effect from an invalid attempt to assign the request to the existing team/owner.. are you able to confirm why/how the analyst in this example is able tot try to assign to the existing team/owner?  I'm just wondering if there is a specific BPM process or action within a process etc that could be causing an issue?

Kind regards,

Dave

[Adrian Simpkins]

Hi David, thank you for looking at this.

The analyst was just assigning a request to another team using the Assign action button in Service Manager after taking action in the request. The board itself is written to via our SLA when certain criteria is met i.e. about to breach Response / Resolution etc, so the analyst never navigates to the escalation board. Currently the escalation board is just available to Managers / Team Leaders.

One thing I noted is when the analyst tried to assign it to another team, this doesn't show in the request immediately, so he tried it again and got the assign error as shown below - when I navigated to the request when he raised it, the error was gone, and the request was assigned to the other team, so the error just appears for him, and I am not seeing it. Also, the request he transferred was not assigned to him, but it was assigned to another member of his team he belongs to.

I have one other full user seeing this error pop up on a few requests, but have had no reports of this from any of the other full users. Again his example is very similar with a BPM with no task / activities set - the BPM was at the stage where it is just Waiting For Resolution.

There was an issue earlier in the year where some of the SLA auto escalation configuration for writing to the board was removed which I had to reset, but these requests have been raised after that issue was fixed (I reset the SLA configuration around writing to the board as no requests were writing to the board due to the missing board lane configuration) The forum post to that just in case: 

 

FYI the bpm behind this request is a basic BPM and has no activities or tasks set in the process. Both requests highlighted were just sitting at Wait For Resolution in the BPM. The request is also in the escalation board correctly (2nd image below)

Many thanks

[David Hall]

Thanks for the information Adrian.. there must be a pretty specific set of circumstances to allow this to happen, I'll do some more digging to see what I can figure out and get back to you.

Kind regards,

Dave.

[Adrian Simpkins]

Thanks Dave - much appreciated !

[Adrian Simpkins]

Hi Dave - the 2 affected Users have reported some more examples of this - should I raise this in as a ticket to the Support team ?

Many thanks

[David Hall]

Hi @Adrian Simpkins

Apologies for the delay in responding, I've been trying again to replicate this issue but unfortunately had little success so far.  I undertook a detailed code review and the code has checks in place for this scenario which should prevent this occurring.  

I note from the screenshot that it appears the analyst was able to press the assign button twice which generated the second warning message on screen.  Normally the button is disabled on the first click to prevent this happening... does every case that has been reported to you have both of these errors?  I'm wondering if there is something speed/timing related that could be a factor as I'm unable to replicate under normal tests locally.  

Also just wanted to check if all of the errors that have been reported to you involve the same service/BPM process or whether it has been reported across various services/BPMs.

Kind regards,

Dave

[Adrian Simpkins]

Hi David

Apologies i have been off ill. 

One of the analysts is new to Hornbill so I suspect he hit Assign twice. The affected requests appear to be across multiple services. I had one of them report another example today and again on a different service. Still only these 2 users that have reported this issue to me though 

Many thanks