Self service permissions > 'Settings' page

[carma12]

This PR depends on this one to be merged: #1153

Summary by Sourcery

Provide end-to-end self-service permission management, including a Settings page for viewing and updating permission attributes.

New Features:

• Add a self-service permissions management page with listing, search, pagination, creation, deletion, and contextual help.
• Add a self-service permission Settings view for editing permitted attributes with save and revert actions.
• Add a reusable checkbox-enabled typeahead control for selecting and filtering multiple values.

Enhancements:

• Add API integration and data handling for self-service permission discovery, display, creation, modification, and deletion.
• Expose self-service permissions through application navigation and detail routes.

Documentation:

• Update documentation links for self-service permissions.

Tests:

• Add component coverage for multi-select typeahead behavior, filtering, selection, and read-only handling.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• In TypeAheadWithCheckbox, the previousTarget/localOptions reset logic calls setState directly during render when creationProps.onChangeTarget changes; this should be moved into a useEffect on creationProps?.onChangeTarget to avoid React warnings and unnecessary re-renders.
• The TypeAheadWithCheckbox component mutates localOptions and availableOptions in the same render cycle and uses eslint-disable to work around useEffect behavior; consider refactoring the options filtering/creation logic into pure derivations from props and input state to make the component easier to reason about and avoid reliance on side effects for basic data shaping.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In `TypeAheadWithCheckbox`, the `previousTarget`/`localOptions` reset logic calls `setState` directly during render when `creationProps.onChangeTarget` changes; this should be moved into a `useEffect` on `creationProps?.onChangeTarget` to avoid React warnings and unnecessary re-renders.
- The `TypeAheadWithCheckbox` component mutates `localOptions` and `availableOptions` in the same render cycle and uses `eslint-disable` to work around `useEffect` behavior; consider refactoring the options filtering/creation logic into pure derivations from props and input state to make the component easier to reason about and avoid reliance on side effects for basic data shaping.

## Individual Comments

### Comment 1
<location path="src/components/TypeAheadWithCheckbox.tsx" line_range="54-57" />
<code_context>
+  const [activeItemId, setActiveItemId] = useState<string | null>(null);
+  const textInputRef = useRef<HTMLInputElement>(undefined);
+
+  const [previousTarget, setPreviousTarget] = useState<T | null>(null);
+  const allowCreation = creationProps !== undefined;
+
+  if (allowCreation && previousTarget !== creationProps?.onChangeTarget) {
+    setPreviousTarget(creationProps.onChangeTarget);
+    setLocalOptions(
</code_context>
<issue_to_address>
**issue (bug_risk):** Avoid calling setState during render when creationProps.onChangeTarget changes

This logic runs during render and triggers `setPreviousTarget`/`setLocalOptions`, introducing side effects in the render phase. In React (especially under StrictMode), this can cause repeated renders and unpredictable behavior. Move this into a `useEffect` that depends on `creationProps?.onChangeTarget` (and `allowCreation`/`options` as needed) so `previousTarget` and `localOptions` are updated after render.

```ts
useEffect(() => {
  if (!allowCreation || !creationProps) return;
  setPreviousTarget(creationProps.onChangeTarget);
  setLocalOptions(
    [...options].sort((a, b) => String(a.value).localeCompare(String(b.value)))
  );
  setInputValue("");
}, [allowCreation, creationProps?.onChangeTarget, options]);
```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[duzda]

On save please clear the attributes box.

Screencast.From.2026-08-19.10-50-04.mp4

[duzda]

Please don't add the barrel file without unit tests.

[carma12]

I can create a unit test for that component.

[duzda]

Strange piece of code but fine with keeping it in. The BasicType is way too broad.

[carma12]

I know, this is my attempt to normalize the values here and preventing undesired values. But now I'm thinking that maybe this can be simplified to something like:

const selectedValues = React.useMemo(() => {
  return toArray(rawValue) as string[];
}, [rawValue]);

Not sure if the casting here will be a bad practice though...

[duzda]

Typically as is a bad practice, but I'd use as here, you're not really narrowing here - the variable is incorrectly typed, you know it's a string, also value "" is still a valid string.

[carma12]

Ok, will change it then.

[carma12]

On save please clear the attributes box.
Screencast.From.2026-08-19.10-50-04.mp4

I have modified the original TypeAheadWithCheckbox component to clear the textinput when the 'X' button is clicked.

[carma12]

Just amended the code mentioned in this comment.

[pranav210798]

batch delete only inspects results[0] ? What if first delete succeeds and a later one fails?

[carma12]

Same: it belongs to PR #1153 and should be fixed there.

[pranav210798]

IPA stores attrs lowercase, but this comparison is case-sensitive typing Mail can show “Create new” next to mail. Lowercase on create and match case-insensitively.

[carma12]

You are right, will fix....

[pranav210798]

Please also validate aciname against ^[-_ a-zA-Z0-9]+$ and reject leading/trailing spaces, this currently only checks that the name is non-empty.

[carma12]

I think this was introduced in the original PR (#1153) from which belongs the first commit of this PR, so maybe should be fixed there.

[carma12]

@pranav210798 - I have amended some of your suggestions, specifically the ones that belong to the current PR / last commit, as it has been built on the top of #1153 and the first commit belong to this one and should be fix there.