Tagged job access not as advertised

[GoogleCodeExporter]

What steps will reproduce the problem?
1. +job/tag <#>=<player>
2. (as player) +job/add <#>=<text>
3. (as player) +myjob/add <#>=<text>

What is the expected output?
According to +jhelp tagging, "If you tag a job to a player that does not have 
access to the jobs system, then the job will show up in +myjobs, and they will 
have FULL ACCESS to that job (i.e., they will be able to read all entries, and 
they will be able to add to that job), no matter if the job is in a public 
bucket or not."

What do you see instead?
Permission denied.

Please use labels and text to provide additional information.
Jobs tagged for a player without access to the jobs system DO show up in 
+myjobs, and they can read the whole job, but contrary to the helpfile there is 
no means for them to add to the job.

Presumably tagging it for someone with +jobs access, but not to that bucket, 
should give them +jobs access, rather than requiring them to +myjobs it.  And 
they still can't /add, either with +job/add or +myjob/add.

Either the /add commands need fixing to allow use by tagged persons, or the 
helpfile should be amended to accurately reflect what's going on.

(Note: if editing ACCESSCHECK fixes this, it will fix the related issue of 
tagged people needing to see broadcast messages about the job as well. If the 
fix is not with ACCESSCHECK, then FIL_BROADCAST needs adjusting.)

Original issue reported on code.google.com by widdis@gmail.com on 1 Sep 2010 at 4:07

[GoogleCodeExporter]

r128 addresses the +myjob/add issue, which answers the helpfile issue. 

But...

There is still inconsistency in how job tagging appears to be implemented and 
I'd like other dev feedback on the original intent and/or where we should go.  
Of note, currently:

1. The +job/add command will UNTAG you automatically.  Presumably the usage of 
tagging for people with access to the job is "read and reply".

2. The +myjob/add command does NOT presently untag you automatically. If you 
don't have access to the job normally, this gives you access until you are 
intentionally untagged.  Usage of tagging for people without access to the job 
is single-job access.

There are some people who have access to the jobs system but not that jobs' 
bucket. Because the tagged job shows up in "MINE" it shows on their +jobs/mine 
or +jobs/all lists, but presently they can't +job # (to read) or +job/add 
(which untags them). They *can* with this bugfix, +myjob # (to read) and 
+myjob/add (which does not untag them).  Is this the way we want to keep it? 

After thinking about this, I think I'd prefer to roll back r128 and NOT use job 
tagging to give players access.  Instead, it seems to me we'd be better off 
creating a new command, +job/access #=<person> to grant access.  Then we could 
have consistent behavior (no untagging, proper listing of +jobs, broadcasting, 
etc.) across all commands.

I will implement the above unless objections are posted here.

Original comment by widdis@gmail.com on 4 Nov 2010 at 8:00

• Changed state: Started

[GoogleCodeExporter]

Above comment should refer to r363. 128 is obviously the issue number. 

Original comment by widdis@gmail.com on 4 Nov 2010 at 9:44

[GoogleCodeExporter]

Proposed solution:

  +job/access <player>=<job>

  This command toggles access to <job> to the named <player>. This allows
  them to bypass the default bucket locks. Access is by +myjob for all
  players, or by +job based on the main lock to access. The GIVE_ACCESS 
  on the Job Database <JD> object is used to control access.

What this will do:
- have a command syntax similar to +bucket/access
- give the +myjobs access currently associated with tagging (and remove that 
aspect of tagging)
- give (or remove) full +jobs access to that job to anyone on +jobs, as if they 
already had (or did not have) access to the bucket.

Note that this will require making all the ACCESSCHECK queries based on the job 
rather than on the bucket.

Original comment by widdis@gmail.com on 8 Nov 2010 at 12:43

[GoogleCodeExporter]

While you're at it, code a +myjob/mail and +myjob/add as distinctly different 
commands.  If players are going to be able to add to jobs they're accessed on, 
they ought to be able to act as admins.

Original comment by kkragenb...@gmail.com on 8 Nov 2010 at 5:19

[GoogleCodeExporter]

Actually that opens up a much larger issue. Should they be able to 
complete/approve/deny the job as well?  Or use the other +job commands?

I doubt that a player who doesn't normally have access to the job system will 
even know (or ever use) what commands are available beyond /add.

Original comment by widdis@gmail.com on 8 Nov 2010 at 5:48

[GoogleCodeExporter]

I think admins should always be responsible for final closure. But having a way 
to communicate with the admins (a la +job/add) that does not alert the other 
players on the job is awfully useful.

Original comment by kkragenb...@gmail.com on 8 Nov 2010 at 5:59

[GoogleCodeExporter]

I think the tagging system needs a complete rethink, yes. It was initially put 
in 
as just a way of letting a player look at a whole job (and upon reading the 
job, 
the access is then revoked). Tagging a job and letting it stay open (until 
/untagged)
is just asking for trouble - once a job reaches 'critical length', how many 
people
continue to look at the header to see who has access?

In terms of +myjob/mail - we are doing an end-run around the system by including
this, and I strongly disagree with its addition. I think if you need to 
communicate
something privately, then you should just simply open a new job and let 
workflow 
deal with it.

Original comment by Fleety...@gmail.com on 10 Nov 2010 at 9:47

[GoogleCodeExporter]

Based on the above, I think:
1. A new +job/access command is necessary to make it clear what we're trying to 
do with it (permanent access to a job you wouldn't otherwise have).
2. Job tagging behavior should be redefined.  I'm not sure how much use it 
currently has... I've only used it on to-all-staff read-and-acknowledge type 
jobs.

Eitherway, FN_ACCESSCHECK needs a complete rewrite.

Original comment by widdis@gmail.com on 10 Nov 2010 at 11:02

[GoogleCodeExporter]

Commencing work on the +job/access command.

Unless anyone objects in the next 24-48 hours, I'm going to revert "tagging" to 
simply something that puts a job on +job/mine until you read it.

Original comment by widdis@gmail.com on 10 Dec 2010 at 11:48

[GoogleCodeExporter]

+job/access has been implemented (r368, r369, r370).

Still need to change tagging behavior (only affects /mine listings and is 
removed upon /add or read of the job.)

Original comment by widdis@gmail.com on 13 Dec 2010 at 12:04

[GoogleCodeExporter]

Tagging behavior altered and documented in r371.

Original comment by widdis@gmail.com on 13 Dec 2010 at 4:28

• Changed state: Fixed