Essentially I am asking for a administrative console setting that can be used to determine how long actions are visible within the console. As you all know to maintain console performance today we are required to delete actions. This is kind of an extreme final course to take to simply improve console performance. Deleting actions also does not make it easy to go back and review if needed.
I work for a MSP and going back to review action history is a very real thing.
So the ask is to provide a way to “hide from console” actions after a desirable time limit, say 30-90 days perhaps, then the console performance is not hindered but actions are still visible via reporting. additionally a way to mark specific actions as “visible” in the console again should others need to review them from the console.
Voted!
…with commentary. Hiding action history based only on action issue date could be complex. What about old Dynamic actions that apply on newly-deployed machines, or Policy actions that reapply on existing ones?
It might be helpful to be able to manually hide actions like we can for Fixlets or Tasks, and use the “Show Hidden Content” button to display them. Also maybe to allow “locally hidden” and “globally hidden” options.
True, I didn’t think about policy based actions, perhaps those could be based on the action executed on the endpoint and not based on the “active” policy itself?
I was thinking more of a BES Admin Setting to set the age of the action history shown in the console. That way it is a global setting vs. a user setting or perhaps it could be a user setting and if you like working under a slow console then that is on you.
I do like the idea of the ability within in the console to hide or unhide the actions as needed and it should be on a per action basis vs. all or nothing kinda thing.
This is very similar to another RFE mentioned here. I suggest we bundle all the hiding/archiving/exporting/datawarehouse into one full-featured request.
From my perspective, I’d like to see the ability to ‘auto-groom’ actions based on rules to a secondary/archive database. It would be great to do that for older custom tasks/fixlets/sites/analyses as well. This would dove-tail with long-requested version-control as well.
I think this type of option would only apply to stopped or expired actions, so policy actions that are still open would not be removed.
The challenge with this idea is that it doesn’t align with how the console and Web Reports function today. The reason actions need to be deleted is so they are not loaded into the memory session that feeds the console/WR (which adds to load time, update time, and resource consumption the larger the session is). Hidden content is still loaded into the session, so you can click that button and quickly see the difference. If they weren’t in the session, then you probably would not like the time it took to view these “hidden” actions. And in order to continue reporting on them, they have to be in the WR session, but not in the console session. Not insurmountable challenges, but something that complicates the architecture noticeably.
In the interim, we did add Audit Log entries for action deletions in 9.5.11, so you can more easily identify actions that were deleted. With the action ID from that audit message, you can easily restore the actions using the ‘undelete_action’ stored procedure, if further details are needed.
Yes, I meant to add that ‘auto-grooming’ would only apply to stopped or expired actions based on rules.
Would it be possible to ‘tag’ actions in such a way that they could be loaded ‘on demand’, but wouldn’t be automatically loaded in the session? If that was possible, I’d probably have a rule that stopped or expired actions older than a month would be automatically groomed to a secondary database where it could be reference on demand.
A lot of this request is possible today with the REST API, but there isn’t much built in to do this without custom content.
The first thing to do is backup all custom content and actions into GIT automatically. There is example content out there to do that now. You might consider backing up actions and content separately, but it can be done together. I would generally backup custom content once a day, but I might want to backup actions once an hour.
WARNING: You probably shouldn’t recreate actions from backup directly in most cases. Better to recreate them over again but using the old one as a guide.
The next thing to do with the REST API is to automatically delete actions that are stopped or expired and older than X days. [ or have been stopped or expired for more than X days ]
Another thing to deal with is what I would call “Open & Completed Actions”, which are actions targeted to specific machines, set to run once and only once, and have run against all of the machines that have been targeted, but have not or never expire. You could deal with these with the REST API, but I also have a console dashboard specifically for this:
You should also audit actions that are targeted to specific machines but have not run against all of them.
The hardest thing to audit is policy actions that never expire and do repeat. I don’t know of an automated way to really handle this case, but you could use a dashboard or similar to expose only those items and make auditing them easier.
Another option is to have less actions by targeting them at automatic groups and changing the automatic group relevance to change the scope of the action instead of taking an action on the same item over and over and over. There are problems with this approach as well, but it is an option. There are other similar things to be done to try to limit the number of actions.