Enhancing IPermissible

[bolto...@gmail.com]

All,

We'd like to take this opportunity to enhance the IPermissible
interface. It might make more flexible to allow a permissible own
targets that have distinct activities. In the current interface, all
targets have to have the same set of activities. We can just modify the
getActivities method to take a target token. For migrating
implementations, they only need to change the method signature at the
very least. Since most folks need to port their code over, I think
this is tolerable.

Also, we can also introduce better labeling for the UI. Instead of just
providing a name, we could provide a display label and description. So
the label would be used for the initial display and tooltips could use
the detailed description.

Thoughts?
-nick

[Andrew Petro]

+1 for enhancing IPermissible to afford differing per-target permitted
activities.

Since the IPermissible interface is changing, I wonder if its name should
change to reflect its new capabilities.

ITargetDifferentiatingPermissible ?

Or something like that. Would this stave off awkward conversations around

"So my code registers an IPermissible"

"Oh? What flavor of IPermissible does it register?"

? Maybe a problem not worth solving, or that is sufficiently solved by new
package namespace.

Also, I wonder about the object design around this. If we're saying that an
IPermissible has different things to say about the activities permitted for
any given Target, then are we really saying that there ought to be a:

IPermissible

IPermissionedTarget getPermissionedTarget()

IPermissionedTarget

Set<Activity> getPermittedActivities();

boolean activityIsAllowed(Activity);

Does this kind of object decomposition better represent the domain? I
suspect it could result in more literate client code -- IPermissionedTarget
sounds like the kind of thing that could be passed off to delegates or
helper methods to do actual work without passing off an entire IPermissible.

The domain of groups and permissions is abstract, to be sure, but some
healthy skepticism around the complexity of IPermissible is warranted as
methods get more complex and parameterized...

+1 for additional metadata around IPermissible -- labels and descriptions
sound good and directly address a major criticism of the present permissions
experience -- frequent feeling of "what is this?". Will these / how will
these be localized? Do they need to return a key which is just-in-time
replaced with a localized string at the view layer?

Andrew

[Andrew Petro]

Pursuant to our merging this list into jasi...@unm.edu, I'd like to move
the conversation there. I've forwarded the email so everyone there can see
the conversation thusfar.

I'm sending an admin subscribe request presently to ensure that everyone on
this list is also subscribed to jasig-dev@. For those of you who are
Uniconers who subscribed via gmail, I will translate to your unicon email
address for that request, i.e. we'll come out the other end with your unicon
address subscribed to jasig-dev.

Andrew