Hi,
I’m observing for a JDBC source that entitlements which were marked ‘requestable’ pre-aggregation, get reset to false post-aggregation.
The understanding I had was that the only place to control requestable status is through the UI/APIs, but is there any way the status can be flipped during aggregation in ISC? Our entitlement aggregation brings in an entitlement attribute “requestable”, but not really sure that takes any sort of precedence over the UI-based manual configurations.
Hi @sushantkulkarni,
Can you share your configuration for the Entitlement Attribute which is requestable ? Do you have an attribute defined at Entitlement Level in ISC ?
Thanks
Rakesh
No, the entitlement schema isn’t really storing that ‘requestable’ attribute. It only captures Entitlement Name and Description.
“Our entitlement aggregation brings in an entitlement attribute “requestable”, but not really sure that takes any sort of precedence over the UI-based manual configurations”
What is the value of the requestable for the entitlement for which you see a flip from requestable:true to requestable:false ?
Thanks
The value is ‘true’ or ‘false’ based on the SQL query’s CASE statement evaluation while aggregating.
It seems like the entitlements are being deleted and recreated. Can you check the ID of a specific entitlement before and after aggregation?
Turns out the issue was with a build map rule staying linked which made API calls to reset the requestable flags. That was unintentional, but expected behavior! I’ll just close this thread for now, but thanks everyone for your help!
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.