Contrast mode updates #2387

benlister-okta · 2024-10-11T18:45:06Z

Summary

Switch the highContrast and lowContrast strings because when you're in a high contrast background, the styles need to be low contrast.
Add a MutationObserver on the background color because it needs to watch for changes.
Add unit tests for verifying the context works correctly
Remove stories showing the gray background in Storybook. Also remove CustomTheme documentation for the Contrast Provider (added in 1.24)
useContrastContext should be renamed useContrastModeContext.
Remove ThemeProvider from ContrastModeProvider.
Move ContrastModeProvider behavior to OdysseyThemeProvider.
OdysseyThemeProvider now accepts contrastMode prop and detects gray 50 by default.

Testing & Screenshots

KevinGhadyani-Okta · 2024-10-14T16:55:55Z

packages/odyssey-react-mui/src/OdysseyThemeProvider.tsx

+import { ContrastMode, getBackgroundColor } from "./ThemeContrastProvider";
+
+const useContrastMode = (explicitContrastMode?: ContrastMode) => {
+  const ref = useRef<HTMLDivElement>(null);


In a future update, we should probably let them pass in their own wrapper. That'll be a separate discussion to have later.

KevinGhadyani-Okta · 2024-10-14T16:57:31Z

packages/odyssey-react-mui/src/OdysseyProvider.tsx

+      shadowDomElement={shadowDomElement}
+      shadowRootElement={shadowRootElement}
+      themeOverride={themeOverride}
+      contrastMode={contrastMode}


I'm concerned about exposing this contrastMode prop. I get why it's here, but we shouldn't need it. For now, it's a fail-safe.

I'm just hoping it won't become a liability. Ideally, we'd mark it as @experimental in TypeScript.

KevinGhadyani-Okta · 2024-10-14T16:58:37Z

packages/odyssey-react-mui/src/OdysseyThemeProvider.tsx

+  const updateContrastMode = useCallback(() => {
+    if (!explicitContrastMode) {
+      const newBgColor = getBackgroundColor(ref.current);
+      setContrastMode(
+        newBgColor === Tokens.HueNeutral50 ? "highContrast" : "lowContrast",
+      );
+    }
+  }, [explicitContrastMode]);


We should be calling these backgroundColor rather than bgColor.

And in this case, I don't think we need to say newBgColor either as that's confusing. That's the current background color.

Suggested change

const updateContrastMode = useCallback(() => {

if (!explicitContrastMode) {

const newBgColor = getBackgroundColor(ref.current);

setContrastMode(

newBgColor === Tokens.HueNeutral50 ? "highContrast" : "lowContrast",

);

}

}, [explicitContrastMode]);

const updateContrastMode = useCallback(() => {

if (!explicitContrastMode) {

const backgroundColor = getBackgroundColor(ref.current);

setContrastMode(

backgroundColor === Tokens.HueNeutral50 ? "highContrast" : "lowContrast",

);

}

}, [explicitContrastMode]);

Also, does this hook need to be here in the first place? We shouldn't be checking for Tokens.HueNeutral50 outside of ContrastModeProvider.

Didn't we remove all this code????

KevinGhadyani-Okta · 2024-10-14T17:02:00Z

packages/odyssey-react-mui/src/OdysseyThemeProvider.tsx

+  useLayoutEffect(() => {
+    const observer = new MutationObserver(updateContrastMode);
+    observer.observe(document.querySelector("html") as HTMLHtmlElement, {
+      attributes: true,
+      attributeFilter: ["class", "style"],
+    });
+    observer.observe(document.head, {
+      childList: true,
+      subtree: true,
+    });
+
+    const onTransitionEnd = (event: TransitionEvent) => {
+      if (event.propertyName === "background-color") {
+        updateContrastMode();
+      }
+    };
+
+    document.addEventListener("transitionend", onTransitionEnd);
+    updateContrastMode();
+
+    return () => {
+      document.removeEventListener("transitionend", onTransitionEnd);
+      observer.disconnect();
+    };
+  }, [updateContrastMode]);
+
+  return { ref, contrastMode };
+};


This code is duplicated in 2 places now. We should only need it in one place.

I remember it working just with the ContrastModeProvider.

KevinGhadyani-Okta · 2024-10-14T17:03:43Z

packages/odyssey-react-mui/src/OdysseyThemeProvider.tsx

+    const customOdysseyTheme = useMemo(
+      () =>
+        createTheme(
+          deepmerge(odysseyTheme, {
+            odysseyContrastMode: contrastMode,
+            ...(themeOverride || {}),
+          } as ThemeOptions),
+        ),
+      [odysseyTheme, themeOverride, contrastMode],
+    );


This didn't have as ThemeOptions in the old code right? I think we don't need it. Unless you're trying to say {} is as ThemeOptions, but that's separate from making the entire response ThemeOptions.

I think this was added for the contrastMode prop, but we don't need that anymore.

KevinGhadyani-Okta · 2024-10-14T17:06:42Z

packages/odyssey-react-mui/src/ThemeContrastProvider.tsx

+    <div ref={ref}>
+      <ThemeContrastContext.Provider value={contextValue}>
+        {children}
+      </ThemeContrastContext.Provider>
+    </div>


This should probably be ThemeContrastModeContext to match the naming.

KevinGhadyani-Okta · 2024-10-14T17:09:54Z

packages/odyssey-react-mui/src/ThemeContrastProvider.tsx

+export const ThemeContrastProvider: React.FC<ThemeContrastProviderProps> = ({
+  children,
+  contrastMode: explicitContrastMode,
+}) => {


We don't need to use React.FC here, and we don't in other places, so I'd prefer we remove it.

Suggested change

export const ThemeContrastProvider: React.FC<ThemeContrastProviderProps> = ({

children,

contrastMode: explicitContrastMode,

}) => {

export const ThemeContrastProvider = ({

children,

contrastMode: explicitContrastMode,

}: ThemeContrastProviderProps) => {

KevinGhadyani-Okta · 2024-10-14T17:11:02Z

packages/odyssey-react-mui/src/ThemeContrastProvider.tsx

+  contrastMode?: ContrastMode;
+};
+
+export const ThemeContrastProvider: React.FC<ThemeContrastProviderProps> = ({


I think this should probably just be named ContrastModeProvider. It'd make a lot more sense with the prop contrastMode, and it has nothing to do with the theme more than it has to do with the current contrast mode.

The theme provider consumes this provider and makes it relevant to the theme, but this provider only cares about setting the contrast mode.

KevinGhadyani-Okta · 2024-10-14T17:13:24Z

packages/odyssey-react-mui/src/theme/ThemeContrastProvider.test.tsx

+jest.mock("../ThemeContrastProvider", () => ({
+  ...jest.requireActual("../ThemeContrastProvider"),
+  getBackgroundColor: jest.fn(),
+}));


I don't think we need to mock ThemeContrastProvider in this test.

If we override what getBackgroundColor does, we can't be sure it's going to work that way when apps use it.

We should wrap this test in a div with a specific background color. That way, we can be sure it's working as-expected.

KevinGhadyani-Okta · 2024-10-14T17:15:45Z

packages/odyssey-react-mui/src/theme/ThemeContrastProvider.test.tsx

+describe("ThemeContrastProvider", () => {
+  beforeEach(() => {
+    jest.useFakeTimers();
+  });
+
+  afterEach(() => {
+    jest.useRealTimers();
+    jest.resetAllMocks();
+  });


We shouldn't need any of these timers, but it might be because we're using requestAnimationFrame. I wonder if we can simply wrap our expect in act to fix it.

KevinGhadyani-Okta · 2024-10-14T17:16:01Z

packages/odyssey-react-mui/src/theme/ThemeContrastProvider.test.tsx

+const TestComponent = () => {
+  const { contrastMode, parentBackgroundColor } = useThemeContrastContext();
+  return (
+    <div role="status" aria-label="Contrast Mode">
+      {contrastMode}:{parentBackgroundColor}
+    </div>
+  );
+};


I don't know why we're creating a TestComponent when we have real Odyssey components we can use to test with.

KevinGhadyani-Okta · 2024-10-14T17:20:14Z

packages/odyssey-react-mui/src/theme/ThemeContrastProvider.test.tsx

+    (getBackgroundColor as jest.Mock).mockReturnValue("#ffffff");
+
+    render(
+      <ThemeContrastProvider>
+        <TestComponent />
+      </ThemeContrastProvider>,
+    );


This is where we can wrap ThemeContrastProvider in a div that includes the background color. You can even make it a styled component. We can avoid all these Jest mocks that way.

To me, jest.Mock is generally code smell.

KevinGhadyani-Okta · 2024-10-14T17:31:05Z

packages/odyssey-react-mui/src/theme/ThemeContrastProvider.test.tsx

+    const { rerender } = render(
+      <ThemeContrastProvider>
+        <TestComponent />
+      </ThemeContrastProvider>,
+    );
+
+    await act(async () => {
+      jest.runAllTimers();
+    });
+
+    expect(
+      screen.getByRole("status", { name: "Contrast Mode" }),
+    ).toHaveTextContent("lowContrast:");


I get why we have a TestComponent now, but I think there's a better way of doing these tests. Instead of having TestComponent with a role, we should just have it render null.

What we want to check isn't that the HTML output is lowContrast, we want to pass a callback onContrast to TestComponent, and we want to verify the value is correct.

A better way

But... There's another way of doing that same thing which doesn't require adding random test components or callback functions.

We can use ContrastModeContext.Consumer, we can pass it a function as children, and capture that value in a variable. Then we can say expect(contrastMode).toBe("lowContrast").

Now, it's type-safe, we know the expected values, and we're not adding extra code that could potentially interfere with our tests.

An even better way

It's been a while since I wrote tests against context in React.

I'm thinking you can use jest.fn to create a function. Use that to store the value of the context.

Then you have more fine control over the current value and can say:

expect(contrastConsumerFunction).toHaveBeenCalledTimes(1) expect(contrastConsumerFunction).toHaveBeenCalledWith({ contrastMode: "lowContrast" })

That's the best way I can think that doesn't require adding any extra code than what's built into React and Jest.

Since we're testing logic, we don't need Testing Library nor accessibility selectors.

Logic testing instead

Thinking about this more, we're essentially testing a hook (all that logic) and testing the output of the context from that hook.

Testing Library has a separate library for testing React hooks. It allows you to "render" the hook and ensure, given certain values, you get a specific outcome. This way, you can test the hook outside of the context provider component, and it should mean you don't have to do such extensive component testing since the hook holds all the logic.

Point is, the way we're testing this today is super hacky and isn't going to catch everything because we're mocking the getBackgroundColor function leaving that completely untested.

And then we're adding more code that could cause us to not test correctly and receive a correct value when it's not correct.

KevinGhadyani-Okta · 2024-10-24T18:15:07Z

packages/odyssey-react-mui/src/useContrastMode.tsx

+const isTransparentColor = (color: string): boolean =>
+  color === "rgba(0, 0, 0, 0)" || color === "transparent";


Suggested change

const isTransparentColor = (color: string): boolean =>

color === "rgba(0, 0, 0, 0)" || color === "transparent";

const isTransparentColor = (color: string) =>

color === "rgba(0, 0, 0, 0)" || color === "transparent";

KevinGhadyani-Okta · 2024-10-24T18:15:19Z

packages/odyssey-react-mui/src/useContrastMode.tsx

+const normalizeRgbaToRgb = (rgba: string): string =>
+  rgba.replace(/rgba\((\d+), (\d+), (\d+), \d+\)/, "rgb($1, $2, $3)");


Suggested change

const normalizeRgbaToRgb = (rgba: string): string =>

rgba.replace(/rgba$(\d+), (\d+), (\d+), \d+$/, "rgb($1, $2, $3)");

const normalizeRgbaToRgb = (rgba: string) =>

rgba.replace(/rgba$(\d+), (\d+), (\d+), \d+$/, "rgb($1, $2, $3)");

KevinGhadyani-Okta · 2024-10-24T18:16:31Z

packages/odyssey-react-mui/src/useContrastMode.tsx

+
+const hexToRgb = (hex: string): string => {
+  const bigint = parseInt(hex.slice(1), 16);
+  const r = (bigint >> 16) & 255;
+  const g = (bigint >> 8) & 255;
+  const b = bigint & 255;
+  return `rgb(${r}, ${g}, ${b})`;
+};
+
+export const hueNeutral50Rgb = hexToRgb(Tokens.HueNeutral50);
+
+const isTransparentColor = (color: string): boolean =>
+  color === "rgba(0, 0, 0, 0)" || color === "transparent";
+
+const normalizeRgbaToRgb = (rgba: string): string =>
+  rgba.replace(/rgba\((\d+), (\d+), (\d+), \d+\)/, "rgb($1, $2, $3)");
+
+const getElementComputedBackgroundColor = (element: HTMLElement): string =>
+  window.getComputedStyle(element).backgroundColor;
+
+const normalizeBackgroundColor = (bgColor: string): string => {
+  if (/rgba\((\d+), (\d+), (\d+), \d+\)/.test(bgColor)) {
+    const normalizedColor = normalizeRgbaToRgb(bgColor);
+    return normalizedColor === hueNeutral50Rgb
+      ? Tokens.HueNeutral50
+      : normalizedColor;
+  }
+  return bgColor === hueNeutral50Rgb ? Tokens.HueNeutral50 : bgColor;
+};


We should have tests for these.

KevinGhadyani-Okta · 2024-10-24T18:19:31Z

packages/odyssey-react-mui/src/useContrastMode.tsx

+  const contrastContainerRef = useRef<HTMLDivElement>(null);
+  const { contrastMode: existingContrastMode } = useContrastModeContext();
+
+  const [parentBackgroundColor, setParentBackgroundColor] = useState("#ffffff");


The default value of "#ffffff" should be in an exported defaultParentBackgroundColor variable.

That way, we can access it in our tests.

KevinGhadyani-Okta · 2024-10-24T18:20:32Z

packages/odyssey-react-mui/src/theme/useContrastMode.test.tsx

+    it("should update contrast mode based on background color changes", async () => {
+      const TestComponent = () => {
+        const { contrastContainerRef, contrastMode } = useContrastMode({});
+        return (
+          <div ref={contrastContainerRef} data-testid="container">
+            {contrastMode}
+          </div>
+        );
+      };
+


This test should probably be in 2 places. Once in OdysseyThemeProvider, and once in getParentBackgroundColor as this hook itself doesn't care nor does it know about getComputedStyle being used.

KevinGhadyani-Okta · 2024-10-24T18:21:21Z

packages/odyssey-react-mui/src/theme/useContrastMode.test.tsx

+    it("returns the background color of the element if it is not transparent", () => {
+      const element = document.createElement("div");
+      element.style.backgroundColor = "rgb(255, 0, 0)";
+      const result = getBackgroundColor(element);
+      expect(result).toBe("rgb(255, 0, 0)");
+    });
+


I like the first test to be the default case, so in this case, if it's transparent.

KevinGhadyani-Okta · 2024-10-24T18:22:15Z

packages/odyssey-react-mui/src/theme/useContrastMode.test.tsx

+      expect(getBackgroundColor(child)).toBe("rgb(0, 255, 0)");
+    });
+
+    it('returns "#ffffff" if no non-transparent background is found', () => {


Suggested change

it('returns "#ffffff" if no non-transparent background is found', () => {

it('returns "#ffffff" if transparent background is found', () => {

KevinGhadyani-Okta · 2024-10-24T18:25:20Z

packages/odyssey-react-mui/src/theme/useContrastMode.test.tsx

+      const child = document.createElement("div");
+      grandparent.appendChild(parent);
+      parent.appendChild(child);
+      grandparent.style.backgroundColor = "rgb(0, 0, 255)";


Suggested change

grandparent.style.backgroundColor = "rgb(0, 0, 255)";

grandparent.style.setProperty("backgroundColor", "rgb(0, 0, 255)");

KevinGhadyani-Okta · 2024-10-24T18:26:27Z

packages/odyssey-react-mui/src/theme/useContrastMode.test.tsx

+      window.getComputedStyle = jest
+        .fn()
+        .mockImplementation((el: HTMLElement) => ({
+          backgroundColor:
+            el === grandparent ? "rgb(0, 0, 255)" : "rgba(0, 0, 0, 0)",
+        }));


Suggested change

window.getComputedStyle = jest

.fn()

.mockImplementation((el: HTMLElement) => ({

backgroundColor:

el === grandparent ? "rgb(0, 0, 255)" : "rgba(0, 0, 0, 0)",

}));

window.getComputedStyle = jest

.fn()

.mockImplementation((el: HTMLElement) => (el === grandparent ? grandparent.style : {

backgroundColor: "rgba(0, 0, 0, 0)",

}));

KevinGhadyani-Okta · 2024-10-24T18:27:49Z

packages/odyssey-react-mui/src/theme/useContrastMode.test.tsx

+  afterEach(() => {
+    window.getComputedStyle = originalGetComputedStyle;
+    jest.clearAllMocks();
+    document.documentElement.style.backgroundColor = "";


I think this is the same, but if not, then put "" instead like it was:

Suggested change

document.documentElement.style.backgroundColor = "";

document.documentElement.style.setProperty("backgroundColor", null);

KevinGhadyani-Okta · 2024-10-24T18:28:24Z

packages/odyssey-react-mui/src/useContrastMode.tsx

+  rgba.replace(/rgba\((\d+), (\d+), (\d+), \d+\)/, "rgb($1, $2, $3)");
+
+const getElementComputedBackgroundColor = (element: HTMLElement): string =>
+  window.getComputedStyle(element).backgroundColor;


Suggested change

window.getComputedStyle(element).backgroundColor;

window.getComputedStyle(element).getPropertyValue("backgroundColor");

this causes the tests to fail and I think we'd have to refactor most of the tests to support it.

KevinGhadyani-Okta · 2024-10-24T18:30:29Z

packages/odyssey-react-mui/src/theme/useContrastMode.test.tsx

+        const event = new Event("transitionend");
+        Object.defineProperty(event, "propertyName", {
+          value: "background-color",
+        });
+        testContainer.dispatchEvent(event);


I think there's a better way to write this without using Object.defineProperty. This might be it though.

We should also comment this to explain why we're going through the trouble of firing the transitionend event.

It might not be an issue with Happy-DOM; that, or we need to wrap it in a waitFor.

Maybe we can simply make the act async.

KevinGhadyani-Okta · 2024-10-24T18:33:34Z

packages/odyssey-react-mui/src/theme/useContrastMode.test.tsx

+      await waitFor(
+        () => {
+          expect(getByTestId("container").textContent).toBe("highContrast");
+        },
+        { timeout: 1000 },
+      );


I wonder if we still need this explicit timeout. No issue if we have it, just wanna make the test simpler.

good call, I tested without it and it isn't needed 🎉

KevinGhadyani-Okta · 2024-10-24T18:37:19Z

packages/odyssey-react-mui/src/theme/useContrastMode.test.tsx

+  describe("MutationObserver functionality", () => {
+    let originalAddEventListener: typeof document.addEventListener;
+    let originalRemoveEventListener: typeof document.removeEventListener;
+
+    beforeEach(() => {
+      originalAddEventListener = document.addEventListener;
+      originalRemoveEventListener = document.removeEventListener;
+      document.addEventListener = jest.fn();
+      document.removeEventListener = jest.fn();
+    });
+
+    afterEach(() => {
+      document.addEventListener = originalAddEventListener;
+      document.removeEventListener = originalRemoveEventListener;
+    });
+
+    it("should clean up observers and event listeners on unmount", () => {


This can be part of the main useContrastMode hook tests because it's part of that hook.

What I'd like to see are the beforeEach and afterEach moved into the hook using the jest.spyOn syntax.

KevinGhadyani-Okta · 2024-10-24T18:38:21Z

packages/odyssey-storybook/src/components/odyssey-mui/Tooltip/Tooltip.stories.tsx

+
+      await new Promise((resolve) => setTimeout(resolve, 500));
+


This should probably be waitFor instead.

KevinGhadyani-Okta · 2024-10-24T20:14:39Z

This PR is almost done! Code's in a great state, and 99% of my comments were on minor updates to improve tests.

…odyssey into bl_contrast_providerupdate

benlister-okta marked this pull request as ready for review October 14, 2024 00:57

benlister-okta requested a review from a team as a code owner October 14, 2024 00:57

KevinGhadyani-Okta reviewed Oct 14, 2024

View reviewed changes

benlister-okta added 15 commits October 17, 2024 13:14

fix: swap low/high contrast values

9790172

fix: implement MutationObserver, remove inner

f69ec1f

fix: move contrast to OdysseyThemeProvider

a05de7f

fix: refactoring with kevin

a16c0f9

fix: cleanup and refactor, add tests

d871904

fix: add style object back

9a13f64

fix: prop reordering

c1ccbf9

fix: update tests

c44f037

fix: fix interaction test

fa168f7

fix: pr feedback

5b85698

fix: revert last commit

db8323b

fix: rename to ThemeContrastModeContext

d97b8d9

fix: remove React.FC

3a30488

fix: rename ContrastModeProvider

422ab77

fix: update tests

c60e6fe

KevinGhadyani-Okta reviewed Oct 24, 2024

View reviewed changes

benlister-okta added 8 commits October 24, 2024 15:21

fix: test and syntax updates

5fa1c22

fix: add basic tests for OdysseyThemeProvider

6c01fcf

fix: test update

8036256

fix: update tests

29f4f1c

fix: add coverage for contrastMode functions

065122e

Merge branch 'bl_contrast_providerupdate' of https://github.com/okta/…

f3623f4

…odyssey into bl_contrast_providerupdate

fix: test updates

e4d1583

fix: update tests, default bg as const

a21c6aa

KevinGhadyani-Okta previously approved these changes Oct 25, 2024

View reviewed changes

Merge branch 'main' into bl_contrast_providerupdate

79f5483

benlister-okta dismissed KevinGhadyani-Okta’s stale review via 79f5483 October 25, 2024 17:15

KevinGhadyani-Okta approved these changes Oct 25, 2024

View reviewed changes

oktapp-aperture-okta bot merged commit 8890b91 into main Oct 25, 2024
3 checks passed

oktapp-aperture-okta bot deleted the bl_contrast_providerupdate branch October 25, 2024 18:25

		const isTransparentColor = (color: string): boolean =>
		color === "rgba(0, 0, 0, 0)" \|\| color === "transparent";

		const normalizeRgbaToRgb = (rgba: string): string =>
		rgba.replace(/rgba\((\d+), (\d+), (\d+), \d+\)/, "rgb($1, $2, $3)");

	it('returns "#ffffff" if no non-transparent background is found', () => {
	it('returns "#ffffff" if transparent background is found', () => {

	grandparent.style.backgroundColor = "rgb(0, 0, 255)";
	grandparent.style.setProperty("backgroundColor", "rgb(0, 0, 255)");

	document.documentElement.style.backgroundColor = "";
	document.documentElement.style.setProperty("backgroundColor", null);

	window.getComputedStyle(element).backgroundColor;
	window.getComputedStyle(element).getPropertyValue("backgroundColor");

Contrast mode updates #2387

Contrast mode updates #2387

Conversation

benlister-okta commented Oct 11, 2024 • edited Loading

Summary

Testing & Screenshots

KevinGhadyani-Okta Oct 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KevinGhadyani-Okta Oct 14, 2024 • edited Loading

Choose a reason for hiding this comment

KevinGhadyani-Okta Oct 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KevinGhadyani-Okta Oct 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KevinGhadyani-Okta Oct 14, 2024 • edited Loading

Choose a reason for hiding this comment

KevinGhadyani-Okta Oct 14, 2024 • edited Loading

Choose a reason for hiding this comment

A better way

An even better way

KevinGhadyani-Okta Oct 14, 2024 • edited Loading

Choose a reason for hiding this comment

Logic testing instead

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KevinGhadyani-Okta Oct 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KevinGhadyani-Okta Oct 24, 2024 • edited Loading

Choose a reason for hiding this comment

KevinGhadyani-Okta Oct 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KevinGhadyani-Okta commented Oct 24, 2024

benlister-okta commented Oct 11, 2024 •

edited

Loading

KevinGhadyani-Okta Oct 14, 2024 •

edited

Loading

KevinGhadyani-Okta Oct 14, 2024 •

edited

Loading

KevinGhadyani-Okta Oct 14, 2024 •

edited

Loading

KevinGhadyani-Okta Oct 14, 2024 •

edited

Loading

KevinGhadyani-Okta Oct 14, 2024 •

edited

Loading

KevinGhadyani-Okta Oct 14, 2024 •

edited

Loading

KevinGhadyani-Okta Oct 14, 2024 •

edited

Loading

KevinGhadyani-Okta Oct 24, 2024 •

edited

Loading

KevinGhadyani-Okta Oct 24, 2024 •

edited

Loading

KevinGhadyani-Okta Oct 24, 2024 •

edited

Loading