Re: Issue 157 in anomalyjobs: Locking +myjobs

[anoma...@googlecode.com]

Updates:
Summary: Locking +myjobs
Status: Accepted
Labels: Type-Enhancement Priority-Medium Plat-All Milestone-Release6.5
Usability

Comment #6 on issue 157 by wid...@gmail.com: Locking +myjobs
http://code.google.com/p/anomalyjobs/issues/detail?id=157

(No comment was entered for this change.)

[anoma...@googlecode.com]

Comment #7 on issue 157 by lasht...@gmail.com: Locking +myjobs
http://code.google.com/p/anomalyjobs/issues/detail?id=157

On the Reach we handled this by giving all of these kinds of staffers
(well, all staffers really) a different parent object that defined a
&cmd_myjobd obj=$+myjob*:@pemit %#=Please use +jobs.

This works fairly elegantly for blocking the scan of the master room,
however it rapidly became apparent that most people don't know to @lock/use
themselves, so that had to be addressed separately.

So maybe best handled by a HOWTO?

[anoma...@googlecode.com]

Comment #8 on issue 157 by wid...@gmail.com: Locking +myjobs
http://code.google.com/p/anomalyjobs/issues/detail?id=157

I'm going to see if I can modify +myjobs to only let you access jobs you
would have accessed if you didn't have full +jobs permission.

[anoma...@googlecode.com]

Updates:
Status: Started

Comment #9 on issue 157 by wid...@gmail.com: Locking +myjobs
http://code.google.com/p/anomalyjobs/issues/detail?id=157

OK, if I understand this right, most of the +myjobs commands are
informational and harmless for a staffer to run. The only concern is the
+myjob/add command.

Broad-based locks will be hard to get right. On my game we have faction
heads who have access to one bucket for all the +jobs stuff, but are just
regular users in other buckets for their +requests, etc.

I think it's reasonably easy to see if someone would have passed the locks
for +job/add and send them there automagically. This will be transparent
to users and accomplish the desired goal.

[anoma...@googlecode.com]

Updates:
Status: New

Comment #10 on issue 157 by wid...@gmail.com: Locking +myjobs
http://code.google.com/p/anomalyjobs/issues/detail?id=157

Well, I put in the code to force +myjobs to +jobs, but then compared the
two commands. They execute identical code internally. (The +jobs version
removes tags, but that's not a big deal.)

So I'm back to wondering what the issue is.

[anoma...@googlecode.com]

Updates:
Status: Fixed

Comment #11 on issue 157 by wid...@gmail.com: Locking +myjobs
http://code.google.com/p/anomalyjobs/issues/detail?id=157

OK, I've gone through all the +myjob commands and don't see any reason to
lock them:

+myjob/help - display only, and actually useful to see what mortals see
+myjob(s)/nospam - new command, identical behavior to +job/nospam
+myjob/sumset - sets myjob summaries; different than +job/sumset; useful to
have
+myjob <job> - display only, harmless to run
+myjob/last - display only, harmless to run
+myjobs - display only, harmless to run
+myjobs/catchup - harmless to run

And finally, the one noted in comments, +myjob/add. After passing checks,
it runs:

{
@pemit %#=Comments to [name(%q0)] added.;
@trigger %va/TRIG_ADD=%q0,trim(%1),%#,ADD;
@trigger %va/TRIG_BROADCAST=%q0,%#,ADD
}

Compared to +job/add, which runs:
{
@pemit %#=Comments to [name(%q0)] added.;
@trigger %va/TRIG_ADD=%q0,trim(%1),%#,ADD;
@trigger %va/TRIG_BROADCAST=%q0,%#,ADD
}

Other than the lack of untagging, the commands are exactly identical. (The
lack of untagging was probably intentional back when tagging was used for
access control; now that tagging is no longer used for that, it should be
added to the +myjobs version.)

In summary, for the stock code there isn't really any reason to lock myjobs
commands. If you've hacked your +myjob/add to behave differently than
+job/add (e.g., mail staff as mentioned in comment 3) then you can also
hack it to add a suitable access check.

r415 aligns +myjob/add exactly with +job/add. Marking this completed.