Admin search throws for permissions added through Admin.generalIndexItems('permissions', ...)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 76/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- php, typescript
Research direction
Start in framework/core/js/src/admin/components/GeneralSearchSource.tsx, at the permissions loop in lookup() identified by the issue. Compare how indexed settings handle plain arrays and inspect the GeneralIndexData permission shape. Reproduce by adding the provided permission entry and searching for “Moderation thing”; done means the search returns it without throwing and uses its link when present.
Written by the indexing model from the issue text.
Description
Current Behavior
Permissions added to the admin search index through Admin.generalIndexItems('permissions', ...) (or app.generalIndex.for(...).add('permissions', [...])) throw as soon as the admin search runs:
TypeError: (permissions[permissionType] || []).toArray is not a function
GeneralSearchSource.lookup() assumes permission data is registry-shaped ({ view: ItemList, ... }) and calls .toArray() on each entry, but GeneralIndexData stores indexed permissions as a plain GeneralIndexItem[]. Settings handle both shapes; permissions do not.
Steps to Reproduce
- Register an indexed permission entry, for example:
app.generalIndex.for('acme-example').add('permissions', [
{
id: 'acme-example.moderation.thing',
label: 'Moderation thing',
link: app.route('extension', { id: 'acme-example', page: 'moderation' }),
},
]);
- Open the admin search and query
Moderation thing. - The search throws and no results render.
Expected Behavior
Indexed permission entries are searched the same way indexed settings are, and an entry's own link is used when present.
Environment
- Flarum version: 2.x (2.0.2, still present on 2.1 dev)
- Location:
framework/core/js/src/admin/components/GeneralSearchSource.tsx, permissions loop inlookup()
Additional Context
Found while working on a fix for #5254. This is pre-existing and independent of that change: the throw happens before any link is read.
- Dominant language
- PHP
- Stars
- 6.8k
- Forks
- 887
- Avg merge
- 11h 45m
- Merged PRs (30d)
- 131
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from flarum/framework
-
Admin search ignores a settings or permissions item's own linkPossibly taken @GBra-4-669 claimed this today. Opentype/bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
type/extensibility
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
All issues in flarum/framework
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
grokability/snipe-it#19869 · 2 comments ·
Maintainers usually reply within 1 day
-
sync-en
Difficulty 1/5 Under an hour Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
sync-en
Difficulty 1/5 Under an hour Newbie friendliness 77/100
Maintainers usually reply within 3 days
-
Перевод устарел
Difficulty 1/5 Under an hour Newbie friendliness 74/100