Hi, This seems very interesting. I would say that the crawler could be a useful tool for developers (to begin with), do you have the code available somewhere ?
Also i am guessing you can only get static permissions, what about permission that depend on a relationship between the current user and an entity ? -- Wickersheimer Jeremy On Wednesday 11 November 2009 12:56:11 Bob Morley wrote: > Have been working on some integration between the various modeled objects > in Ofbiz and came across a requirement to allow specification of required > permissions for a controller request. Effectively what I have been > working on is the ability to walk various model graphs extend behaviour to > one model from the other. What I have working so far is some extension > and clean-up to the presentment model, control model, and service model > including the ability for these models to accept a visitor. > > So far I have only really worked on base visitors that navigate through a > model or crawl from one model to another model. This has enabled us to > write some interesting unit tests -- for example, by starting with the > controllers I was able to crawl through every screen in the system which > crawled the various soft links to forms, menus, trees, etc. Failures were > reported in the unit test; so in effect the unit test verifies that you > have not created any bad includes. From the source I had I only found one > error in the set of Ofbiz screens (lots in our hot-deploy) :) > > Other interesting things become possible. For example, one could get the > entire list of screens (from standard means) and then start with the > controllers they could crawl through all controller requests to the various > presentment artifacts making note of each screen that gets hit (either > directly or from crawling the decorators/include-screens/etc) making note > of each screen found. In the end you can fail on any defined screens that > are not referenced anywhere in the system. > > By far the most interesting thing I am working on, and the reason for this > message, is the ability to apply behaviour from one model to the other. > Using the current method of setting permissions, we were thinking of > something like this. > > a) In general define permissions at the service definition. > b) Between loading the controller requests and storing them in the cache, > we will walk the controller requests to the service defintion; gather up > the permissions; and dynamically apply them to the controller request map. > This modified model would be cached with new "permission" objects on the > controller requests. > > Now while this does not get you very much (failing in the controller is not > much different than failing in the service dispatcher); it does get us to a > point where we can apply a similar pattern when loading / caching the model > screens. Specifically, if you have created an xml representation of a menu > link when you walk the presentment model and hit that link you can crawl > over to the related controller requests. This has been cached now with > permissions which you could then apply to the menu link. In short, if you > do not have permission the menu link now is not rendered. Again you would > do this crawl at load/cache time and the modified object model would be > cached, so there is no expensive visiting at render time. > > Does anyone want to have a dialog about possible community interest in > these set of enhancements? I am more than willing to explain things > further, make adjustments, packing them up, etc. Back to the original > subject; I can also piece out the change that gave control requests the > ability to define required permissions (understanding that there is some > work underway to change how permissions are done). >
