For your first question, that's changing with Work Centers where they're designed to be stateless and retrieve data from the Maximo system via REST API. But with the legacy UI as you've mentioned a refresh won't trigger a refetch of the record. As a stateful application, the server is maintaining the MBOs (and corresponding MBOSETs) for tracking records that have been modified and how they've been modified. When you use the "Find", what you're really doing is adjusting the where clause the application uses and resetting that set to contain only those MBOs. It's not really a "refresh" in that sense.
For your second question, you probably could create an action automation script that does what you want but my experience with UI work is limited. I've done some simple navigation from one record to another using the below (replacing UNIQUEID with the ID of course).
webSession=service.webclientsession()
webSession.getCurrentApp().getAppBean().moveToUniqueId(UNIQUEID)
And this works to navigate to a new record (including records that aren't part of your set) but doesn't seem to work in the simple refresh scenario. I think you'd have to get the AppBean's find() function to work somehow or at least mimic some of what they're doing. The function is designed around the WebClientEvent being the user utilizing the find, which won't be the case here (it'll be the user invoking your action), so that might be tricky to make it work. But implementing a subset of it seemed to work well for me.
appBean=webSession.getCurrentApp().getAppBean()
resultsBean=appBean.getResultsBean()
resultsBean.resetQbe()
resultsBean.getMboSet().ignoreQbeExactMatchSet(False)
resultsBean.setUserWhere("")
resultsBean.setQbe("workorderid","="+str(mbo.getUniqueIDValue()))
resultsBean.reset()
resultsBean.next()
resultsBean.getMboSet().ignoreQbeExactMatchSet(True)
------------------------------
Steven Shull
Director of Development
Projetech Inc
Cincinnati OH
------------------------------