Dashlet code improvements

We have a situation where a client using SSL client authentication can't use dashlets because they do an internal https request not using the certificate resulting in the dashlet rendering as "An authorized SSL client certificate is required to access this server."

I had a long discussion with Coleman & Tim on IRC about this and we agree that the current dashboard code could be improved and simplified. Currently the dashlets are resolved by an internal http request. As this is server to server (er yes ... the SAME server) the client side credentials are not available at this point.

We considered a few possibilities but our consensus was that we should return a url to the browser which is could load using ajax. This would allow the browser to use it's certificate & reduce server over-head.

A concern was that we would lose the current dashlet caching however this was mitigated by the fact that
a) the caching could be done in browser with the right headers
b) the caching is being done per contact anyway - so expensive reports are rendered once per contact.

We did discuss how we might cache expensive reports & that will be recorded in a related issue.

Other interesting approaches we discussed included

1) flexible retrieval options
This basically means that a url COULD be stored in the url field but alternatively it could be a reference to an api call, object or method. The Resolver class is already pretty powerful in dealing with this and this would make dashlets more flexible and powerful. There would be a need to ensure people couldn't create dashlets 'above their paygrade' e.g with the api create a dashlet that calls a scary function.

Core_Resolver (already) supports formats like:

• static function: 'CRM_Myext_Mydashlet::render'
• API: "apiv3://Mydashlet/render?foo=bar"
• service (in Civi\Core\Container): "call://service/method"

Technically I don't think there is a downside to this & the above approach doesn't preclude this happening as well. However, an extra api action to retrieve report html would be required and probably some work to deal with the report classes expectations about having a url - which would be good to do but does involve work. We would also possibly consider figuring out ways to return other api data as html & the possibilities that might open up.

As a fix this doesn't allow things like civisualise to work in a dashlet so it isn't a fl fix in itself.

2) internal invoke
This is the idea we could set up various temporary globals within a php request & call CRM_Core_Invoke. There is some precedent for this in test suite and expanding the scope of this would expand options for testing forms & pages without invoking selenium.

As the current intent of dashlet caching is basically to cache search results we discussed how that might look & I will log that to a separate ticket. IRC log attached (far to long to paste in!)