After we made updates to our Business Role descriptions, we were a bit surprised to see the old descriptions showing up in new requests and work items.
We were expecting that the new definitions would show up on anything that was created after our update.
It seems like either the information is cached somewhere, or the new requests are looking at old requests to get the description rather than the current definition of the role.
In the debug page, you can reset configuration caches. You may want to give that a try.
You can find that in the dropdown that says “Configuration Objects”.
There’s also a separate page, accessible from the wrench menu, where you can reset various caches.
$URLROOT/identityiq/debug/caches.jsf
Thanks, these were my first thought, as well as rebuilding the full text indexes. Apologies, I should have noted what I had already tried. EDIT: I also restarted a Tomcat on a couple of servers to see if this was cached at that level.
The other thing that I was hoping to understand is where descriptions of assigned roles on the Entitlements page of the Identity warehouse are coming from. These are a mixed bag of old and new, mostly old. The ‘newly created items’ is a more cut and dried scenario.
When I look at the data for assigned roles and roleAssignments (identity preferences) I see references to the associated bundle by id, but the only place there seems to be any copy of the description is in the workflow case before it is approved.
Also of note, I updated the en_US description using a rule with thisBundle.addDescription(locale,newDescription);
I have examined the Bundle definitions via debug and see that the intended value is there, and the old is not.
<entry key="sysDescriptions">
<value>
<Map>
<entry key="en_US" value="This is a new description."/>
</Map>
</value>
</entry>
</Map>
</Attributes>
Is there by any chance an attribute just called “description” in your Bundle? I’m wondering if someone incorrectly added an attribute just called description rather than the proper locale description map. Maybe the Full Text Index and other pages are picking that up?
Thanks, we have reset caches (configuration, miscellaneous, managed attribute, and IntegrationConfig), rebuilt full text indexes, and restarted Tomcat. Still there a month later…
Alas, Production Environment. However, an experiment today may shed some light on this. We exported an affected bundle as xml, and then reimported it, and success. So… perhaps it has something to do with the way the update was made (via API, setting via the bundle’s addDescription method)