Missing Fiscal Calendar Option in All Times Series Reports
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
In Time-series reports - under trend by Calendar field 'Fiscal Calendar' is no longer an option to be selected. It is available for admins, but not for non-admins.
Checked:
- com.snc.fiscal_calenda plugin is Installed
- Verified the table used in reports is listed in calendars_for_package
- fiscal calendar table exists (fiscal_period.list)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello @shrutishruti,
Turn on Debug Security Rules while impersonating one of the affected users, then reopen the report and try to select Fiscal Calendar in the Trend by: Calendar list. You'll find it under System Security > Debugging > Debug Security Rules (or just append &sysparm_debug=security to the report URL), and it will name the exact ACL that's blocking the read for that session. That's the fastest way to stop guessing and go straight to the record.
The reason admins see it and nobody else does, even though the plugin, calendars_for_package, and fiscal_period all check out, is that admin bypasses ACL evaluation almost entirely. The Trend by: Calendar picker only lists calendars the logged-in user can actually query, not every calendar that technically exists. So a calendar row that's correctly scoped in calendars_for_package can still be invisible to everyone but you if the underlying tables are locked down.
Once the debug log names the failing rule, work through this:
- Check the read ACL on fiscal_period, since it's an admin-facing config table under System Definition and often ships (or gets customized) with a restrictive role requirement.
- Check the read ACL on calendars_for_package itself, that one is easy to overlook because you were checking that a row exists there, not whether non-admins can read it.
- If the failing ACL uses a role condition, the fix is to add that role to the affected users' group rather than loosening the ACL itself, that keeps the fix scoped to the group instead of opening the table more broadly.
- If it's a script-based condition instead, check what it's actually evaluating (roles, company, or a scoped app check) since those don't always fail the way you'd expect.
One small thing worth double-checking on your end too: the plugin ID is com.snc.fiscal_calendar. If what's installed shows as com.snc.fiscal_calenda in your notes, that's probably just a typo when you wrote this up, but it's worth confirming in Plugins that you're looking at the right activated record.
Thank you,
Vikram Karety
Octigo Solutions INC