How to restrict Delete option for 'cache managers'

I am new to this forum and to WebMethods, so please forgive me if this is a rookie question…

What product/components do you use and which version/fix level?

webMethods Integration Server 10.3.0 IS_10.3_Core_Fix5

What are trying to achieve? Please describe in detail.

Recently we had someone ‘delete’ cache managers instead of just ‘clearing’ them. It was most probably a user mistake, with the clear and cach options being right next to eachother ( Webmethods IS → Settings → Caching → click on to see the cache list → there are delete and clear options there.

By deleting the cache manager the code we used in our solution application was failing. We were able to restore it by reloading the cache manager config xml file after retrieving it from another environment.

To prevent this from happening again, we are looking for a way to just remove the delete option from the cache manager UI… I can do that by modifying WmRoot/pub/settings-cache-manager-view.dsp and just remove the ‘delete’ buttons there. That works, but I was told not to do that is updating WmRoot might eventually cause problems with starting webmethods.

Obviously a better solution would be to achieve this through a functional way, probably with ACLs, but I could not find anywhere if we can control this specific thing with ACLs. Would that be possible? If so, how?

Hi @jdegraaf ,
This level of fine grained control is not possible with the current UI, however I recall a custom package (not officially supported) that has a read only version of the all admin pages , maybe this would help you.
Searching for read only IS Admin UI in this forum gives some hints on how to achieve this,
e.g, Read/only role for IS console access - Forum - webMethods - Software AG Tech Community & Forums
note that I haven’t tested any of these and hence would not be in a position to recommend any of those.
Perhaps someone else can pitch in with better solutions.

-NP

NP rightly notes above, that there isn’t a read-only UI.

Since you are familiar with DSPs and ACLs, you can build your custom pages (stored under custom packages), perhaps by collating and adapting portions from the internal DSPs as needed. Yes, this is some work.
Note that you will be using WmRoot services anyway if you do the above, whose direct use isn’t officially supported.

Having said that, from 10.5, most of these operations are made available via Admin APIs.

KM

For info, we do have plans to provide a read only dashboard for key attributes in the future. This makes sense especially when running webMethods containers as they should be immutable and hence you shouldn’t make changes.
John.

thanks for you responses. It is appreciated!

Taking a hint from something I read somewhere else I was able to achieve what I needed through ACLs. I cannot ‘hide’ te delete options, but at least I can make their use ‘denied’ :slight_smile:

  1. Create ‘WmPrivate’ ACL (this is cheeky because it should already exist as an internal one)
    Security → ACLs → Add and Remove ACLs
  2. Assign WmPrivate ACL to the Administrator user group
  3. Create a new ACL called Customexclude (ACLs → Add and Remove ACLs). This ACL does not need to be assigned to any user or group
  4. go to Packages → Management → Browse Folders
  5. go to wm → server → ehcache → admin
  6. click on the Execute ACL for deleteCache
  7. Change the Execute ACL from ‘WmPrivate’ to ‘Customexclude’
  8. Save changes
  9. click on the Execute ACL for deleteCacheManager
  10. Change the Execute ACL from ‘WmPrivate’ to ‘Customexclude’
  11. Save changes
  12. Back in ACLs → select the WmPrivate ACL and remove the local/Administrators group from the ‘Allowed’ groups
  13. Save changes

Now go to Setings → Caching → click on the delete button for a cache manager (may add one for testing first) → click on the OK button in the popup
→ Get an Access Denied message
Similarly, click on the cache manager to see it’s cache list; try to delete one of them. After hitting OK on the popup, it will say ‘Access Denied’