jmcqueen/wxccai
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

[blocker] Grant service account Assets Object Schema role on Stores schema (68) #1

New issue
Open
opened 2026-07-01 16:06:32 -04:00 by jmcqueen · 2 comments
jmcqueen commented 2026-07-01 16:06:32 -04:00
Owner
Copy link

The webex-bot-fzjq885stn service account currently has no role on the Assets Stores schema (id 68), so every AQL query returns HTTP 200 + total: 0. Jira Assets enforces schema-level role membership on top of OAuth scopes; the granted read/write:cmdb-*:jira scopes are necessary but not sufficient.

Fix: Jira → Assets → Object schemas → Stores (68) → Configure → Roles → add webex-bot-fzjq885stn@serviceaccount.atlassian.com as Object Schema User (read + reference) or Developer (also allows creates/updates).

Verification: curl -s $HOST/api/wxccai/debug/assetsProbe?storeNumber=2000 | jq .diagnosis should return likelyCause: "success" or "value_format_mismatch" — never object_type_forbidden again.

Blocks #2.

The `webex-bot-fzjq885stn` service account currently has no role on the Assets Stores schema (id 68), so every AQL query returns HTTP 200 + `total: 0`. Jira Assets enforces schema-level role membership on top of OAuth scopes; the granted `read/write:cmdb-*:jira` scopes are necessary but not sufficient. **Fix:** Jira → Assets → Object schemas → Stores (68) → Configure → Roles → add `webex-bot-fzjq885stn@serviceaccount.atlassian.com` as **Object Schema User** (read + reference) or **Developer** (also allows creates/updates). **Verification:** `curl -s $HOST/api/wxccai/debug/assetsProbe?storeNumber=2000 | jq .diagnosis` should return `likelyCause: "success"` or `"value_format_mismatch"` — never `object_type_forbidden` again. Blocks #2.
jmcqueen added this to the v1: Jira lifecycle GA milestone 2026-07-01 16:06:32 -04:00
jmcqueen added the
blocker
 label 2026-07-01 16:06:32 -04:00
jmcqueen commented 2026-07-06 17:04:03 -04:00
Author
Owner
Copy link

Update from probe run on 2026-07-06: partial success — issue stays open.

What changed

The role grant did land. GET /objectschema/list now returns HTTP 200 (was silently returning empty / 403) and the service account can see 2 schemas:

  • id=68 AE Asset Management (ASSET)
  • id=1 Services (SVC)

Why the AQL still fails for stores

The retail-store objects live in a different schema we still can't see.

Concrete proof: I searched project SS for tickets with customfield_10261 populated and got 5 recent hits (SS-20873, SS-20871, SS-20870, SS-20869, SS-20868). Their customfield_10261 values reference these Assets object ids:

78558, 75857, 82200, 78585, 89079

For every one of them:

  • GET /object/{id} → HTTP 403 "Sorry, you do not have permission to perform this action."
  • AQL objectId in (78558, 75857, 82200, 78585, 89079) unscoped → HTTP 200, total=0. Assets silently filters out objects in schemas the caller has no role on.

Also relevant: the object type id=109 we've been configuring against doesn't exist in either visible schema (GET /objecttype/109 → 403), and the object type literally named "Store" in schema 68 (typeId=180, 1000 rows) turns out to hold Apple devices — iPhones/iPads with serials like C00260K7MG, models like iPad mini A17 Pro. Schema 68 is the device inventory schema, not the stores schema.

Admin action needed

Grant the service account Object Schema Viewer on the schema that actually contains retail stores.

Easiest way to identify that schema without guessing:

  1. Open SS-20871 ("Store 514 - Register 2 CD stuck connecting to server") in Jira.
  2. Click on the Store Number = 514 reference in the ticket.
  3. The URL will be .../browse/assets/{schemaId}/object/{objectId} — that {schemaId} is the one we need.
  4. Jira → Assets → Object schemas → {that schema} → Configure → Roles → add webex-bot-fzjq885stn@serviceaccount.atlassian.com as Object Schema Viewer (same role that was granted on 68).

Once the second grant lands

Rerun the probe. If it comes back green, we also need to update two env vars in .env before closing:

  • JIRA_ASSETS_STORE_SCHEMA_ID → the newly-granted schema id
  • JIRA_ASSETS_STORE_OBJECT_TYPE_ID → the real store type id (currently 109, which doesn't exist in this tenant — the probe will tell us the correct one)

Then #2 (finalize resolveStoreAssetReference to the winning AQL variant) can proceed.

**Update from probe run on 2026-07-06:** partial success — issue stays open. ### What changed The role grant did land. `GET /objectschema/list` now returns HTTP 200 (was silently returning empty / 403) and the service account can see **2 schemas**: - `id=68 AE Asset Management (ASSET)` - `id=1 Services (SVC)` ### Why the AQL still fails for stores The retail-store objects live in a **different schema** we still can't see. Concrete proof: I searched project `SS` for tickets with `customfield_10261` populated and got 5 recent hits (SS-20873, SS-20871, SS-20870, SS-20869, SS-20868). Their `customfield_10261` values reference these Assets object ids: ``` 78558, 75857, 82200, 78585, 89079 ``` For every one of them: - `GET /object/{id}` → **HTTP 403** `"Sorry, you do not have permission to perform this action."` - AQL `objectId in (78558, 75857, 82200, 78585, 89079)` unscoped → HTTP 200, `total=0`. Assets silently filters out objects in schemas the caller has no role on. Also relevant: the object type `id=109` we've been configuring against doesn't exist in either visible schema (`GET /objecttype/109` → 403), and the object type literally named "Store" in schema 68 (`typeId=180`, 1000 rows) turns out to hold **Apple devices** — iPhones/iPads with serials like `C00260K7MG`, models like `iPad mini A17 Pro`. Schema 68 is the device inventory schema, not the stores schema. ### Admin action needed Grant the service account **Object Schema Viewer** on the schema that actually contains retail stores. Easiest way to identify that schema without guessing: 1. Open **SS-20871** ("Store 514 - Register 2 CD stuck connecting to server") in Jira. 2. Click on the `Store Number = 514` reference in the ticket. 3. The URL will be `.../browse/assets/{schemaId}/object/{objectId}` — that `{schemaId}` is the one we need. 4. Jira → **Assets → Object schemas → {that schema} → Configure → Roles** → add `webex-bot-fzjq885stn@serviceaccount.atlassian.com` as **Object Schema Viewer** (same role that was granted on 68). ### Once the second grant lands Rerun the probe. If it comes back green, we also need to update two env vars in `.env` before closing: - `JIRA_ASSETS_STORE_SCHEMA_ID` → the newly-granted schema id - `JIRA_ASSETS_STORE_OBJECT_TYPE_ID` → the real store type id (currently `109`, which doesn't exist in this tenant — the probe will tell us the correct one) Then #2 (finalize `resolveStoreAssetReference` to the winning AQL variant) can proceed.
jmcqueen commented 2026-07-07 08:02:06 -04:00
Author
Owner
Copy link

Update 2026-07-07: refined diagnosis after inspection from an admin account.

The previous comment guessed the retail-store schema was a different schema than 68. That was wrong — verified with curl from an account that has broader Assets visibility.

What we now know is true

The service account's .env config has been correct all along:

Setting Value Correct?
JIRA_ASSETS_STORE_SCHEMA_ID 68 (AE Asset Management) ✅
JIRA_ASSETS_STORE_OBJECT_TYPE_ID 109 (Store Address / Hierarchy) ✅
JIRA_ASSETS_STORE_NUMBER_ATTRIBUTE Store Number (attribute id 635) ✅
Storage format for store 514 "00514" (5-digit zero-padded) matches our padStart(5, '0') ✅

Direct object fetch from an admin account:

GET /jsm/assets/workspace/{ws}/v1/object/75857
→ {
  "id": "75857",
  "objectKey": "ASSET-75857",
  "label": "00514",
  "objectType": {"id": "109", "name": "Store Address / Hierarchy", "objectSchemaId": "68"}
}

And the exact AQL that resolveStoreAssetReference generates returns the object correctly from an admin account:

POST /jsm/assets/workspace/{ws}/v1/object/aql
  { "qlQuery": "objectTypeId = 109 AND \"Store Number\" = \"00514\"", "resultPerPage": 1 }

→ { "total": 1, "first": { "id": "75857", "key": "ASSET-75857", "label": "00514", "typeId": "109" } }

So the code is done. No code change on our side is needed.

What's still blocking

Object type 109 Store Address / Hierarchy is inside schema 68, but the service account still gets 403 on both GET /objecttype/109 and GET /object/75857, and its AQL for objectTypeId = 109 ... returns total=0. Yet the service account CAN run AQL against schema 68 broadly and CAN see other object types in it (Pillar, Components, Vendors, Category, etc.).

That combination is only possible if:

  1. The object type Store Address / Hierarchy has its own Configure → Permissions override that's stricter than schema 68's role, OR
  2. The schema-level role granted to the service account is not high enough — e.g. Object Schema Anonymous (very limited) or Object Schema Viewer when a per-type permission requires Object Schema User or higher.

Another supporting data point: GET /objectschema/68/objecttypes from the admin account returns only 10 top-level types (Pillar, Components, Vendor Contact Card, ComponentLink, Application, IT DR Tier, Vendors, POD, Category, ServerRole) and Store Address / Hierarchy is not in that list — which means type 109 is nested inside a folder/subgroup within the schema. Folders in Assets can carry their own permissions independently of the parent schema.

Refined admin ask

In Jira → Assets → Object schemas → AE Asset Management (68):

  1. Locate object type 109 Store Address / Hierarchy (it's nested — look inside the store/location folder or expand the tree). Right-click / open its Configure → Permissions panel. If it has any explicit permission override, either remove it, or add webex-bot-fzjq885stn@serviceaccount.atlassian.com (and/or the group it belongs to) with read permission.
  2. Check the parent folder if the type is nested — folders can also override permissions.
  3. Verify the schema-level role on schema 68 is at least Object Schema User (not Anonymous). User is the minimum for reliable read access across all types in the schema.

How to verify once done

The app has a diagnostic endpoint. Start the app locally (npm start) and run:

curl -sS 'http://localhost:1866/api/wxccai/debug/assetsProbe?storeNumber=514' | jq .diagnosis

Expected: likelyCause: "success" and the variants array will show attr_name_padded (objectTypeId = 109 AND "Store Number" = "00514") with total=1. When that passes, this issue closes and #2 stays closed.

**Update 2026-07-07: refined diagnosis after inspection from an admin account.** The previous comment guessed the retail-store schema was a *different* schema than 68. That was wrong — verified with curl from an account that has broader Assets visibility. ### What we now know is true The service account's `.env` config has been correct all along: | Setting | Value | Correct? | | -------------------------------------- | ---------------------------- | -------- | | `JIRA_ASSETS_STORE_SCHEMA_ID` | `68` (AE Asset Management) | ✅ | | `JIRA_ASSETS_STORE_OBJECT_TYPE_ID` | `109` (Store Address / Hierarchy) | ✅ | | `JIRA_ASSETS_STORE_NUMBER_ATTRIBUTE` | `Store Number` (attribute id `635`) | ✅ | | Storage format for store 514 | `"00514"` (5-digit zero-padded) | matches our `padStart(5, '0')` ✅ | Direct object fetch from an admin account: ```json GET /jsm/assets/workspace/{ws}/v1/object/75857 → { "id": "75857", "objectKey": "ASSET-75857", "label": "00514", "objectType": {"id": "109", "name": "Store Address / Hierarchy", "objectSchemaId": "68"} } ``` And the exact AQL that `resolveStoreAssetReference` generates returns the object correctly from an admin account: ```bash POST /jsm/assets/workspace/{ws}/v1/object/aql { "qlQuery": "objectTypeId = 109 AND \"Store Number\" = \"00514\"", "resultPerPage": 1 } → { "total": 1, "first": { "id": "75857", "key": "ASSET-75857", "label": "00514", "typeId": "109" } } ``` So the code is done. No code change on our side is needed. ### What's still blocking Object type `109 Store Address / Hierarchy` is inside schema 68, but the service account still gets **403** on both `GET /objecttype/109` and `GET /object/75857`, and its AQL for `objectTypeId = 109 ...` returns `total=0`. Yet the service account CAN run AQL against schema 68 broadly and CAN see other object types in it (Pillar, Components, Vendors, Category, etc.). That combination is only possible if: 1. **The object type `Store Address / Hierarchy` has its own Configure → Permissions override** that's stricter than schema 68's role, OR 2. **The schema-level role granted to the service account is not high enough** — e.g. `Object Schema Anonymous` (very limited) or `Object Schema Viewer` when a per-type permission requires `Object Schema User` or higher. Another supporting data point: `GET /objectschema/68/objecttypes` from the admin account returns only 10 top-level types (Pillar, Components, Vendor Contact Card, ComponentLink, Application, IT DR Tier, Vendors, POD, Category, ServerRole) and `Store Address / Hierarchy` is **not in that list** — which means type 109 is nested inside a folder/subgroup within the schema. Folders in Assets can carry their own permissions independently of the parent schema. ### Refined admin ask In Jira → Assets → Object schemas → **AE Asset Management (68)**: 1. **Locate object type `109 Store Address / Hierarchy`** (it's nested — look inside the store/location folder or expand the tree). Right-click / open its **Configure → Permissions** panel. If it has any explicit permission override, either remove it, or add `webex-bot-fzjq885stn@serviceaccount.atlassian.com` (and/or the group it belongs to) with **read** permission. 2. **Check the parent folder** if the type is nested — folders can also override permissions. 3. **Verify the schema-level role** on schema 68 is at least `Object Schema User` (not `Anonymous`). `User` is the minimum for reliable read access across all types in the schema. ### How to verify once done The app has a diagnostic endpoint. Start the app locally (`npm start`) and run: ```bash curl -sS 'http://localhost:1866/api/wxccai/debug/assetsProbe?storeNumber=514' | jq .diagnosis ``` Expected: `likelyCause: "success"` and the `variants` array will show `attr_name_padded` (`objectTypeId = 109 AND "Store Number" = "00514"`) with `total=1`. When that passes, this issue closes and #2 stays closed.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
cursor/init-repo-and-jira-lifecycle
cursor/close-tickets
cursor/stores-cache
cursor/hardening-4-5-6-7
No results found.
Labels
Clear labels   
blocker

Blocks other work

  
bug

Something is broken

  
cleanup

Housekeeping / hygiene

  
easy

Low-effort

  
enhancement

New capability / improvement

  
followup

Depends on other work

  
refactor

Non-behavioral code rework

No labels
blocker
bug
cleanup
easy
enhancement
followup
refactor
Milestone
Clear milestone
No items
No milestone
v1: Jira lifecycle GA
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: jmcqueen/wxccai#1
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?