Details
-
Bug
-
Resolution: Fixed
-
Low
-
None
-
Severity 3 - Minor
Description
Issue Summary
Using the Admin Page module, when setting custom icons for subpages using a local resource as seen on Custom UI the icon loads successfully for the main page but does not render for sub-pages, even when using the same resource and icon as in the main page.
Note: If we use an external source for the sub-pages' icons, it works fine.
Steps to Reproduce
Use the manifest file below as a template to reproduce the issue.
modules: jira:adminPage: - key: customicons-admin-page title: customIcons layout: basic resource: adminPageBuild icon: resource:appIcons;dog1.png sections: - header: Workflow Whiz Settings pages: - title: Home route: "/" icon: resource:appIcons;dog1.png - title: Sub Page One route: "/sub-page-one" icon: resource:appIcons;dog3.png - title: Sub Page Two route: "/sub-page-two" icon: https://<external_URL_for_icon> resolver: function: admin-pg-resolver function: - key: admin-pg-resolver handler: index.handler resources: - key: adminPageBuild path: static/admin-page/build tunnel: port: 3000 - key: appIcons path: static/admin-page/icons permissions: scopes: - storage:app - manage:jira-configuration - read:jira-user - read:jira-work - write:jira-work content: styles: - unsafe-inline scripts: - unsafe-inline - unsafe-hashes external: images: - "*.<external_domain_here>" app: id: xxxxxxxxxxx
Note - we have used:
- The same icon - dog1.png - , from the same resource for the main page “customIcons”, and sub-page “Home”;
- Another icon, from the same resource, for sub-page “Sub Page One”, which also does not render;
- An external source for the icon seen on sub-page “Sub Page Two”, which shows up fine
Expected Results
All icons should render, for both main and sub-pages, be it from local resource or from external URL
Actual Results
- The sub-page icons, coming from local resource, DO NOT render.
- Main page icon renders fine
- sub-page icons coming from external URLs render fine.
Workaround
Currently there is no known workaround for this behavior. A workaround will be added here when available