[BUG] Case details "Custom Attributes" tab does not highlight or switch correctly (page_uid never assigned)

[Scharxi]

Describe the bug

When a Custom Attribute definition is configured for the case object type (Manage → Attributes → Cases), opening a case's details modal shows one extra pill/tab per attribute group, in addition to the fixed "Info" and "Access" tabs. On open:

• The wrong tab is highlighted as active by default (the custom attribute tab, instead of "Info").
• Clicking between tabs does not correctly swap the visible content — the custom attribute tab shows the same content as another tab, so the attribute fields never actually become visible, even though they are present in the page's HTML.

To Reproduce

1. Go to Manage → Attributes → Cases, define a new attribute group, e.g.:

   {
     "Investigation Metadata": {
       "MITRE ATT&CK Tactic": {"type": "input_string", "mandatory": false, "value": ""},
       "Business Impact": {"type": "input_select", "mandatory": false, "value": "Medium", "options": ["Low", "Medium", "High", "Critical"]}
     }
   }

   Save.
2. Open any case.
3. Click the case's severity/status/state/classification badge (or any trigger that opens the "Case details" modal via case_detail()).
4. Observe the tab bar at the top of the modal.

Expected behavior

"Info" is the active/highlighted tab by default. Clicking "Investigation Metadata" switches the visible pane to show the configured attribute fields with their current values.

Actual behavior

"Investigation Metadata" is shown as the active/highlighted tab on open instead of "Info" (see attached screenshot). Clicking between tabs does not reliably swap the displayed content — the attribute fields do not appear.

Screenshots

Tab bar on open, "Investigation Metadata" incorrectly highlighted instead of "Info":

Info | Access | Investigation Metadata (third pill rendered with the active/dark style)

Root cause analysis

page_uid is used to namespace the generated DOM ids for every attribute tab and field, e.g. in source/app/templates/modals/modal_attributes_tabs.html:

id="{% if is_case_page %}itab_{% endif %}{{page_uid}}{{ outer_loop.index }}_{{ ca.lower()|replace(' ','_') }}"

This same pattern is used in 12 templates covering every object type with custom attributes (case, asset, ioc, task, note, event, evidence, customer): modal_case_info_from_case.html, modal_add_case.html, modal_add_case_asset.html, modal_add_case_ioc.html, modal_add_case_task.html, modal_add_case_event.html, modal_add_case_rfile.html, modal_note_edit.html, modal_add_customer.html, modal_preview_attribute.html.

page_uid is never assigned anywhere in the codebase — no {% set page_uid %}, no page_uid= kwarg on any render_template() call reaching these templates. It always renders as an empty string, so every attribute-tab block across the whole application produces the same unscoped id pattern (1_<slug>, 2_<slug>, ...) with no per-object/per-modal namespacing.

Bootstrap 4's data-toggle="pill" resolves its target pane by reading the link's href as a document-global CSS id selector (not scoped to the surrounding .tab-content), while the pill-highlighting logic is correctly scoped to the enclosing .nav. An id collision therefore breaks only the pane-switching half, leaving the pill highlighting visually "working" but pointed at the wrong tab — which matches the observed symptom exactly.

Supporting evidence that this id-namespacing was never finished: is_case_page (the flag that adds the itab_ id prefix) is only ever set to True in modal_add_case.html — so the identical "case" attribute set renders under two different id schemes depending on which page/modal displays it.

Verified separately that this is a client-side issue, not a data/template bug: the server-rendered HTML for GET /case/details/<id>, fetched in isolation, is correct — the "Info" nav-link carries class="nav-link active show", and the attribute tab's fields carry their correct stored values.

Desktop (please complete the following information):

• Browser: Chrome/Edge (Bootstrap 4.6.2 bundled)
• Version: v2.4.29

Additional context

Suggested fix: assign a real unique page_uid (e.g. object type + object id, or a per-render UUID) at every render_template() call that reaches modal_attributes_tabs.html, so generated ids can never collide between simultaneously-open modals/tabs on the same page.