Assignment Groups

[GoogleCodeExporter]

On a couple projects I've had, it's been useful to be able to assign a job
to a pre-defined group of people. On one level this may seem to reproduce
the use of buckets, but its actually a bit more of a fine grained thing.

For example, we have an ALL group (as opposed to unassigned), to indicate
everyone should look at it. Also an APPLICATIONS group that contains
staffers who handle apps. Another one is like, EXECSTAFF.

The key here is that if you're in one of these groups, these jobs show up
on your +jobs/mine.

The APPLICATIONS one is totally redundant to the APPS bucket, but the
others aren't; EXECSTAFF may collectively be needed to check over something
if its in any number of buckets, and ALL is a special notice that
/everyone/ should comment.

We could create an ALL bucket, but that ruins the ability to use buckets to
separate -types- of jobs, which is a different thing then assigning to
named groups.

How I've implemented this on one project is to @pcreate these users so that
there's a minimum of changes necessary to Jobs itself. 

These players are given Job access (HAS_ACCESS allows anyone with
_JOBACCESS = 1), and have a _GROUP_MEMBER ufun that returns 1 if %# is a
member of the group or 0 if not. 

I could submit the feature if its thought to be useful in general. There's
various other possible implementations if the player one wasn't desired;
the ufuns can just be stored on %va. 'IN_(group)' or some such. That's a
bit less hacky, really. :) Still!

Original issue reported on code.google.com by apt.shan...@gmail.com on 22 Oct 2007 at 10:22

[GoogleCodeExporter]

What if we changed the behaviour of +job/tag somewhat? +job/tag currently 
allows you
to tag multiple people and when they are tagged in a job, that job shows up in 
their
+jobs lists. 

So let's say we dropped the +job/tag feature of having the tag removed when a 
comment
is added as the first step. Second modifed the jobs list or added a marked to 
clearly
denote that a job was tagged (as right now you only know this by looking). 
Third,
show the tag list in the job header. Fourth, add a command for configuring tag
groups. IE, a game could create a tag group called code with the four coders 
listed.
Fifth, allow jobs to be assigned to a tag group. 

I think this would build on the code already in place and, if done, could avoid 
the
whole need to create a PC.

Original comment by grey...@gmail.com on 22 Oct 2007 at 11:06

• Changed state: Accepted

[GoogleCodeExporter]

I had forgotten tags existed; that would all work, I think. 

However, the "command for configuring tag groups" would need to be settable as 
an 
function. I don't want to have to manage +job lists independently of other 
system
lists, I'd rather be able to call isstaff(%#,execstaff) or some such then 
constantly
add/remove people from these lists.

(I have no idea what you mean by 'having the tag removed when a comment is 
added as
the first step' -- huh?)

#5 is basically the most essential. Using the tag machinery seems more 
complicated
then just modifying the joblist and /assign command; but I can see some use. If 
only
to allow groups to contain players.

Original comment by apt.shan...@gmail.com on 22 Oct 2007 at 11:20

[GoogleCodeExporter]

If I tag a job for someone, the tag is removed when they do a +job/add.

Original comment by grey...@gmail.com on 22 Oct 2007 at 11:31

[GoogleCodeExporter]

Original comment by grey...@gmail.com on 29 Oct 2007 at 4:24

• Added labels: Milestone-Release5.3

[GoogleCodeExporter]

I've been musing over potential implementations for this.  I see two key 
requests:
groups for "Assigned-to", and more clearly designating tagged jobs.  Regarding 
the
five points in comment 1:

1. I'm not in favor of removing an expected behavior of tagging.  Seems that 
tagging
should be a temporary "read this" thing, whereas the assigned-to would ensure 
that a
job automatically shows up on appropriate groups' +jobs/mine somewhat 
permanently.

2. Currently we have a * denoting new activity.  We could have a + symbol in its
place to represent tagged, and update the legend in the footer appropriately.

3. Easy to add tagged somewhere in job header.

4 & 5. Tags seem similar to buckets. In theory the same set of commands for 
+buckets
could also be used for +assignlists.  Given the need to associate each 
assignlist
with multiple things (description, function of players assigned, additional 
players
in group) it seems an object (similar to the bucket objects) would be 
appropriate. 
If so, the question arises where to put these objects. %va holds jobs and %vc 
holds
buckets.  Currently %vb is empty...

So, idea would be to store an object inside %vb whose name is the assignment 
group
name, uses a speechlock for regular members of the group, and who can have 
additional
members assigned with an /access command.

Thoughts?

Original comment by widdis@gmail.com on 22 Dec 2009 at 3:39

[GoogleCodeExporter]

If we're going to go with the assignlists (which I think is a fine idea), let's 
also 
make sure we can +job/assign and +job/tag to them.  Additionally, assigning to 
an 
assignlist should require some sort of indicator, like +job/assign 123=+staff, 
and 
+job/tag 123=+apps loki grey.  The + would denote 'this is distinctly an 
assignlist', 
and should not only make finding the list easier, but remove the potential for 
namespace conflict with player names.

I DON'T think we need to add a + for tags in the jobs list, but adding the list 
of 
tags to the job header is a good idea.

I also am not in favor of removing the expected behaviour of tagging.

Original comment by kkragenb...@gmail.com on 22 Dec 2009 at 2:05

[GoogleCodeExporter]

I like the + indicator on lists. Matches @malias concept and makes matching 
names vs.
lists easy.  Will add to /assign and /tag (and might as well /source and /query 
for
completeness?)

Adding to jobs header is trivial. 

But how else (if not + for *) could we denote in the jobs list that a job has 
been
tagged for you, essentially a "read this and reply" alert like those little red 
flags
in MS Outlook?

Original comment by widdis@gmail.com on 22 Dec 2009 at 4:20

[GoogleCodeExporter]

I don't think we need a way to note it in the jobs list.  Tagged jobs already 
show up 
in +jobs/mine.  That's where most people should be looking for things 
assigned/tagged 
to them.

Original comment by kkragenb...@gmail.com on 22 Dec 2009 at 10:31

[GoogleCodeExporter]

Working on a possible implementation of this (called jgroups for the moment), 
very
similar to the existing bucket code.  What it does:
- creates an object (similar to bucket) stored in %vb with name matching list, 
desc,
and an ISMEMBER attribute: a boolean function which defaults to
t(member(v(memberlist),%0)
- deleting list destroys said object
- +jgroup/member *=* toggles memberhip of players in memberlist.  If ISMEMBER is
replaced by another function call (e.g., isstaff(%#,execstaff) as in comment 2) 
then
this would be meaningless.
- +jgroups lists the contents of %vb by name and desc.

Advantages:
- boolean ISMEMBER is useful for determining whether to display in +jobs/mine 
- presence of an object makes it easy to check names/lists of groups/etc. 
- can copy bucket code and have similar behavior :)

Disadvantages:
- If user overrides the ISMEMBER behavior it'd be annoying to detect in order to
display appropriate message for adding new members. Would like a cleaner way of
detecting that.
- There are a few times it will be useful/required to get a list of all members 
of a
jgroup.  (1) Unlike the bucket/info, a list of only connected players is 
probably not
sufficient.  (2) For +job/tag with a list it needs to tag them individually so 
they
can be removed individually. (3) There's the potential of having to @mail them. 
 This
is difficult to do without a search() (which differs between servers).  I don't 
see
anyway around this without directly accessing memberlist (and not permitting the
"override" from comment 2).

Thoughts?  Other ideas?

Original comment by widdis@gmail.com on 28 Dec 2009 at 5:17

[GoogleCodeExporter]

First draft at this uploaded as r202.  Thoughts in comment 9 still apply.  
Decision
point needed on +job/tag behavior:

Should +job/tag add the dbref of the jgroup to the tag list?  This is easily 
done
when tagging, but requires more complex code to remove the jgroup when any of 
the
members read it.

Or, should +job/tag add dbrefs of individuals to the tag list (shortcut to 
+job/tag
<each member's name>).  This avoids having to change other tag code.  But 
requires
getting a list of all members of the jgroup... easily done if it's the 
memberlist,
but harder to do (search all players and filter by ismember) if using the 
general
version mentioned in comment 9.

Original comment by widdis@gmail.com on 11 Jan 2010 at 6:53

[GoogleCodeExporter]

OK... as of r207, I went ahead and implemented the second option of comment 10: 
when
+job/tag or +job/untag is used, the jgroup (+apps, etc.) is simply expanded 
into its
list of members.

So say +apps contains members Alice, Bob, and Carol.  "+job/tag +apps Bob Dave" 
will
do the same as "+job/tag Alice Bob Carol Bob Dave" (the duplicates will be 
removed by
setunion).

With this implementation of tagging, all the other code for tags is already up 
to
date, including headers, etc.

I think this implementation is mostly complete.  Review/comments welcome.

Original comment by widdis@gmail.com on 12 Jan 2010 at 7:28

[GoogleCodeExporter]

Reviewing comments, the following is still todo:

1. add something in the header listing who's tagged on the job. Perhaps a 
special
"This is tagged for you" if %# is tagged.

2. do similar expansion of +jgroup names for /source and /query that was done 
for
/tag and /untag.  Might not be used much, but makes sense that anytime a list of
names is acceptable a jgroup should also be. 

3. Potentially add a +jgroup/info command that lists all members of the jgroup.

4. Scour the code for everywhere ASSIGNED_TO is used and make sure it can 
handle the
list.

Original comment by widdis@gmail.com on 12 Jan 2010 at 7:44

[GoogleCodeExporter]

I like the idea of making it simply an expansion.  Also, using this for /query 
and 
/source is actually an EXCELLENT idea; I can think of dozens of uses for that 
in my 
regular usage of the jobs code.

+jgroup/info = bonus good idea. Please do that one.

Original comment by kkragenb...@gmail.com on 12 Jan 2010 at 8:23

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I am not in favor of this type of implementation - it is what buckets are 
supposed
to be for - but I can see the potential for usefulness across a wide range of 
systems. There's enough potential to warrant its inclusion so I'm not going
to reject the idea or try to argue anyone out of the change. That is pretty much
why I've been quiet on this issue. I'm against it, but I'll bite my NO 
ASSUMPTIONS
dev philosophy bullet and accept the change with pride. :)

Besides, one game I work at wanted something similar, so I've seen the behavior
in the wild. In their implementation, they use an object named 'ALL' or 'STORY',
but there's no list associated with it. It's the staffer's responsibility to 
look
at what they see tagged for these objs (it only works in assign, IIRC). This 
has the
drawback of limiting the 'group' system, but has the benefit of reducing the
the amount of complicated interactions with other commands, like the coding 
ballet
you are presently performing. (It's a Good Ballet, don't get me wrong.)

That said, the implementation and ideas that widdis has come up with are
excellent. +jgroups as a name is a good name for it, I can't think of anything
else to call it without adding excessive carpal tunel.

C12.1: This is a good idea. It should only display if tagging is present. A 
'tagging is present' check is already on the footer. If C12.1 is implemented, 
the footer stuff should be removed.

C12.2: I'm not sure if Kevin thought you were talking about turning this into
a plugin. If so, then I vote no; it has extremely useful potential in the 
default
rollout. If not, I too like the idea of /source and /query. Is there any where 
else
that it could be implemented?

C12.3: Very important for keeping track of the lists.

C12.4: Even more important. :)

My own points:

1. Needs to be reconciled with the BLETTER behavior and the <code>_ACCESS stuff,
both of which are in the bletter.txt document. I can do the fixes if need be,
neither are difficult.

2. Nope, can't think of anything else. Looks good, so far.

Original comment by Fleety...@gmail.com on 12 Jan 2010 at 7:01

[GoogleCodeExporter]

(As a side note, the term 'buckets' comes from the AS400 ticketing system in 
use by
MCI/Worldcom during the late 90's/early 00's, upon which Jobs is inspired. A 
bucket
was a department's responsibility - everyone in that dept was supposed to read 
it if 
it was open in their bucket, which is sort of why I'm against the ideas of 
'groups' 
in general - we technically already have them, and incorrect usage is what is 
necessitating this change. However, it still has potential use, even if people 
are
Doing It Wrong.) ;)

Original comment by Fleety...@gmail.com on 12 Jan 2010 at 7:35

[GoogleCodeExporter]

I was initially kinda with Fleety419 on the idea as applied to assign (vs. 
buckets).
 When responsibility is shared, nobody's responsible. :)  But hey, it was requested
and it's not too hard to implement. 

But there's a subtle difference between buckets I'm responsible for and buckets 
I'd
like to look at jut for info, and this change makes that distinction possible.  
For
example, say on my game I'm responsible for the "BUILD" and "CODE" buckets and
interested in a hodgepodge of other buckets, but not "responsible".  How do I 
get a
list of jobs that I am really, no-kidding, on the hook for tracking?

Currently, I'd have to type three commands:  +jobs/list code, +jobs/list build, 
and
+jobs/mine.

With +jobs/select my task is shorter:  +jobs/select bucket=code | bucket=build 
| mine

With jgroups, if I'm a member of +coders and +builders, and &ASSIGNED_TO is set 
on
those buckets by default (either on bucket which is inherited, or hooked to add
conventionally), then a simple +jobs/mine automatically pulls up the same list
(except those jobs another coder or builder has claimed).

So +jobs with monitored buckets shows my "interest" but +jobs/mine (with the 
whole
bucket in "mine" except what's specifically not mine) shows my responsibility.  

Separately, I think the "list" concept as employed in /tag and /untag (and soon
others) is very useful addition in that it's simply a "macro" but the remainder 
of
jobs behavior remains the same. Things like "all admin read and acknowledge 
this" can
be handled with +job/tag +admin or somesuch rather than having to individually 
add
admin names.

Original comment by widdis@gmail.com on 12 Jan 2010 at 9:34

[GoogleCodeExporter]

Ok, r211 implements Comment 12 points 2, 3, and 4.  

Need the bletter updates and review of header/footer id of tagging to see if we 
want
to keep it or change it.

Original comment by widdis@gmail.com on 13 Jan 2010 at 1:25

[GoogleCodeExporter]

Bletter updates in. Will create new issue for tag header/footer changes as 
those are
actually independent of this issue.

Original comment by widdis@gmail.com on 13 Jan 2010 at 7:59

• Changed state: Fixed