bumbleworks/bumbleworks — pull request #3 by ravigadad (2013-05-11 20:10:29+00:00)
Title: Use 'role' instead of 'actor'

**Ravi**
I totally disagree with 'actor' instead of 'role' in Bumbleworks. What's your rationale?

**Dave**
Roles are something users are assigned to and have permissions, etc. Task participants can be a user, a role, any string you want to use, or a regex matching something. It's a different thing.

**Ravi**
Ruote participants can be anything you want them to be. But a "task," which is something we've glommed on, is a Bumbleworks concept, and is performed by any entity in a given role. There's no enforcement that it's a user, but that entity is performing a task within a given role. Using the term "actor" similarly connotes an active entity, but is missing the implication that the entity is acting *as* something in order to perform the task. You're sending in the role, not the actor.

An actor implies that we're talking about the specific entity, not the role which that entity is playing.

I don't actually think roles are specifically "something users are assigned to." Any entity can be "assigned to," or act as, a role. I think a user itself is an actor. You say "participants" can be users, but that doesn't actually make sense. If you chose to write a task such as `dave_miller :task => "argue_with_ravi"`, that would just be a task assigned to anyone with the dave_miller role. If you want your Bumbleworks *client* to assign an exclusive role to each user, you can do that, and then only Dave Miller would have that role. But Bumbleworks shouldn't care about the difference between a "user-specific" role and a "team" role, or even an "any string you want to use" role. They're all roles to Bumbleworks.

The concept of a "participant" is confusing, I agree. It implies that we're talking about an individual entity participating in the workflow. But in this case, the "participant" is Ruote's StorageParticipant, and we're pulling the item from the queue and using our *own* logic to identify who is eligible to perform this task.

Anyway, I feel pretty strongly about this, but obviously I'm always open to being convinced otherwise.

Also, that was a lot of words for a Friday night. But I *am* on an airplane with nothing better to do. :)

**Dave**
I understand that the word "role" is best for this method for the reasons you've described, but since the goal of bumbleworks is to enable web apps to integrate BPM, and web apps already use the word "role" (in the user-role-permissions sense), then it will be confusing to developers

When trying to grasp the concept of a participant, we will be forcing them to ask "Is a role always a role?" And we'll have to answer, "No, a role can be a role, or a user, or anything. It's just a name for any storage participant, the workitems of which we call 'tasks'"

To avoid differentiating between a task-role (or bumbleworks-role) and a user-role, I thought that we should just choose a different word. Actor isn't great, but for one, an entity that is called an actor, necessarily has a role (unlike your waitstaff in LA or New York). `Task.for_actor(:admin)` and it's matching definition:

```ruby
Bumbleworks.define_process 'make_point' do
admin :task => 'approve change'
end
```

...does not cause so much cognitive dissonance to me that it is confusing. "Actor" isn't a commonly used programming word, so this method defines it. The sentences "The actor is an admin" and "The actor is dave_miller" both make perfect sense and adhere to common usage.

You don't have to explain: "While you can use dave_miller as a participant name, what you are really doing is creating a dave_miller role and assigning it only to dave_miller and then using `Task.for_roles('dave_miller')` to pull up tasks for dave_miller." Huh? My users have usernames and my roles are "superuser" and "admin" and "restricted" and I want to define processes with tasks for any or all of those things.

OK then, let's call all of those things "actors".

Upshot: "roles" is great for nuanced reasons, but it's commonly used in a different way in the context we want Bumbleworks to live in, so we should use a different, admittedly less great, name to facilitate the understanding of who/what can do a Task.

**Ravi**
The idea behind the Bumbleworks Task queue is that by convention, you'd *always* use roles. You'd never want to use a username, or some other arbitrary token. Bumbleworks is heavily opinionated, obviously, but that's most of its raison d'etre - to be an opinionated, convention-based wrapper around ruote. We don't want users to think about participants when they're creating "tasks" - it's too esoteric. I don't think we *want* clients of Bumbleworks to differentiate between a task-role and a user-role - they should be the same thing. My point was that the "dave_miller" example was contrived and isn't actually something you'd do in real life.. because why would you create a process with tasks that only Dave Miller can accomplish? Forcing you to think about "roles" instead enforces a best practice that Bumbleworks is heavily pushing.

If you take a situation in which Dave Miller has the role of admin, Dave Miller is the actual actor, *acting as* an admin. In fact, we'd usually do a query like `Task.for_roles(dave_miller.roles)` since we want to get all tasks for *all* roles that Dave Miller is assigned to (I've added this method locally, but haven't pushed up my commits yet because of this naming conflict). If we did `Task.for_actors(dave_miller.roles)`, that makes no sense at all. If Dave Miller is the actor, then semantically you'd want to have this (I understand this isn't what you are proposing): `Task.for_actor(dave_miller)`. But obviously Bumbleworks wouldn't (and shouldn't) do the "expected" thing here - instead it would look up all workitems for which the participant reference was the actual dave_miller object, which would never return anything.

I guess what I'm trying to say is: I *want* Bumbleworks roles to be equated to your application's user roles. It's up to your application whether those roles are first-class concepts, or associations that can be assigned to more than just "users," or whatever. Bumbleworks is just another client of your role/permissions system - you've decided, in your process definitions, what permissions (to accomplish certain tasks) a given role has.