console roles

[tom.baeyens]

yesterday during the meeting with the sa's one of the interesting feedbacks was : we have JON for operators (or linux propellorheads as burr called them :-) and we have our own GWT console that is targetted as different roles.

in the past it has been difficult to isolate those roles in the web application. as typically powerusers want to navigate from any place to any place. so it becomes difficult to offer e.g. only the task mgmt part to a task-clerk. or to embed the operator part of our console (looking and retrying failed jobs, number of optimistic locking exceptions) in JON.

our formost interest is to ship a project to the community that can get us adoption. so it definitely requires a console to be included that can show off the jbpm capabilities.

features like task lists, process monitoring, analythics and operational functions are targetted at different audiences. but how can we structure our own console towards these different roles without crippling the powerusers that want to do it all and navigate conveniently.

so how can we make parts of this web app exposed to a single target role ? and how can we leverage these components in let's say JON/JOPR and maybe Guvnor.

thoughts ?

[heiko.braun]

yes, that was my idea aswell: implement the monitoring a top of jopr and embed the jopr console into the gwt console. so it can be used standalone or as part of jon. I'll probably be able to look into it in the next iteration.

[koen.aers]

Wouldn't it be possible to reuse the perspective concept as it is used in Eclipse? A perspective is a set of views/editors/actions/menu items that is configurable. A user can always change it, but there is a fixed default. Users can also define their own perspectives.
The target roles would then all have one particular perspective.

Cheers,
Koen

[tom.baeyens]

Wouldn't it be possible to reuse the perspective concept as it is used in Eclipse?

conceptually that is indeed what we want.

question remains *how* this can be done.

an aspect that is not yet clear to me is authorization. to what extend should these roles be tied to authorization. if we do that, then parts of pages or views need to become optional. then making sure that the screens/views still render nice will be a challenge.

also we would have to specify for each link, button, column in a table etc which roles are allowed to see it.

all this seems like a very complex matter to get right.

so my current line of thinking would be : keep it simple as long as we don't know exactly what we want to achieve with the complexity we introduce. in other words, i rather ignore roles for now instead of ending up with something that doesn't support roles properly.