ISC UI fails again with newly introduced functionality for partial admin user levels

Feedback Bugs
, , , ,
1

Hi all, :slight_smile:

This error occurs in our production environment.

We have an identity with these user levels: Role Sub-admin, Source Sub-admin.
When this identity goes to the sources page in the UI, it will show this error:

image
image492Ă—183 16.7 KB

This occurs when the UI tries to call this API endpoint: beta/discovered-applications

The issue occurs with sub-source admin, but also with source admin, not with org_admin

I am noticing a pattern of UI errors in the UI in production for users that have some admin rights, but not full on ORG_ADMIN. I believe SailPoint should check if or they are actually testing UI changes on all user levels prior to releasing it, or how/when they are doing it, because that seems to be the crux of this pattern of bugs.

Kind regards,
Angelo

2

Hi Angelo, do you know if SailPoint released some videos / blog posts with insights on how their engineering team is working and what tools they may be using?

Something along these lines: GitHub - kilimchoi/engineering-blogs: A curated list of engineering blogs

I am highly interested in how they perform their testing (unit tests, integration, regression, end to end etc), write the specifications, manage bugs etc.

3

This is a black box to me, but given the amount of bugs that manage to make its way to our production tenants, I would argue that whatever process they have or which tools they use, this should be reviewed.

4

Update from SailPoint Support:

Just checked, issue is still there.

5

I can see a fix is pushed by the engineering team and I am unable to replicate on my test setup.

What does “a fix is pushed” mean?

From my current understanding they deploy some bug fixes over weeks, and we have no official way to know when something is deployed on our tenants, so did they push this fix on your tenant as well?

6

Do you know the answer to this one @colin_mckibben?

7

Code changes aren’t typically deployed to all tenants at once. We do phased rollouts to catch issues early and ensure a code change doesn’t have widespread impacts. A “fix is pushed” might mean that your tenant has the fix, but other tenants won’t get it for days/weeks.

1 Like
8

Makes a lot of sense @colin_mckibben! However, if I am the one creating a support ticket to SailPoint Support, and they reply to me saying the fix has been deployed and ask me to test it, I do expect that it is at least already pushed to the tenant I mentioned when creating the ticket. Is there a way for SailPoint Support to see if this is pushed to specifically my tenant already and only then ask us to test it?

1 Like
9

They should be able to ask engineering for a list of tenants/regions where it was deployed. If they give you a generic “it should have been deployed”, try asking them if your tenant is included in the deployment.

10

Alright will do! I do think however that it would be good if this is part of their training to confirm this first. As I think this process:

  1. Engineering team says fix is pushed to Support
  2. Support asks Engineering team if our tenant is included in the deployment already, until it actually has.
  3. Support tells us the fix is deployed and asks us to test it.
  4. We test, based on actual changes made

Makes more sense then this process:

  1. Engineering team says fix is pushed to Support.
  2. Support tells us the fix is deployed and asks us to test it.
  3. We learn from Colin to first ask Support if this deployment actually included our tenant
  4. Support asks Engineering team if our tenant is actually included in the deployment already until it has.
  5. Support tells us the fix is deployed and asks us to test it.
  6. We test, based on actual changes made
11

Update from SailPoint Support:

13 hours ago, the engineering team was able to fix the bug. SailPoint Support will check if this fix has been deployed successfully.

12

Received a new update from SailPoint Support today:

Just checked, issue is not visible anymore. Note that this bug was reported a month ago, where 16 days ago we got the first (wrong) claim that the fix was pushed and only now we received a correct claim that the issue was fixed.

@community_moderators, please apply the fixed tag here, as I am not authorized to do this myself.

Kind regards,
Angelo

1 Like