Locking +myjobs

[GoogleCodeExporter]

Splitting +myjob* and +job* commands out onto separate objects would allow 
easier locking of those commands to different groups.

As-is, yes, players are prevented from running +job* with a Permission Denied 
message.

It's frequently useful to prevent staffers from accidentally running +myjob 
commands and being able to lock those so staff can't run them would help.

Original issue reported on code.google.com by lasht...@gmail.com on 30 Jun 2011 at 4:27

[GoogleCodeExporter]

While I agree that splitting commands to different objects makes locking 
easier, I don't see the benefit of introducing yet another object to the 
system.  What's wrong with staff using +myjob anyway?

Original comment by widdis@gmail.com on 30 Jun 2011 at 6:05

[GoogleCodeExporter]

Hoping to get Loki to comment, but he's been busy.

For certain setups, inadvertantly using +myjob when you are supposed to use 
+job (e.g. when servicing a player's job) will almost work but silently not do 
certain things like send mail, which ends up contributing to communication 
breakdowns.

Original comment by lasht...@gmail.com on 1 Jul 2011 at 11:15

[GoogleCodeExporter]

Well I actually agree with widdis, here; I still don't see the benefit of 
adding another object to the system. 

That said, it probably would be beneficially to add a lock attribute that get 
called by the myjobs commands so that it's POSSIBLE to lock staff out of using 
those commands.

The big thing is that +myjob/add "mails" players.  Staff may inadvertently mean 
to use +job/add, but use +myjob/add out of reflex, and mail comments they did 
not want mailed.  Because Staff have higher access, effectively every "myjob" 
is available to them, and +myjob/add checks whether you have access, not 
whether you are sourced.

Original comment by kkragenb...@gmail.com on 1 Jul 2011 at 10:36

[GoogleCodeExporter]

IIRC, myjob commands do not trigger off any ADD action hooks, as well, which 
would be
problematic beyond the standard @mailings. I would go with kevin's suggestion of
locking staff out of +myjob commands, or, better yet, perhaps make +myjob/add
automatically reroute a staff member's command to +job/add without fuss.

Original comment by Fleety...@gmail.com on 2 Jul 2011 at 10:39

[GoogleCodeExporter]

I think the problem here is having "myjob" access to jobs you wouldn't 
otherwise have; there are times a staff member might have responsibility for 
one bucket (to use jobs) but not another (but may have a +request in as their 
playerself).  There's certainly room for refining permission access, even if 
it's not on separate objects.

Original comment by widdis@gmail.com on 2 Jul 2011 at 10:53

[GoogleCodeExporter]

Original comment by widdis@gmail.com on 22 Nov 2011 at 8:09

• Changed title: Locking +myjobs
• Changed state: Accepted
• Added labels: Type-Enhancement, Priority-Medium, Plat-All, Milestone-Release6.5, Usability

[GoogleCodeExporter]

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?

Original comment by lasht...@gmail.com on 22 Nov 2011 at 11:56

[GoogleCodeExporter]

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.

Original comment by widdis@gmail.com on 22 Nov 2011 at 5:39

[GoogleCodeExporter]

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.

Original comment by widdis@gmail.com on 23 Nov 2011 at 5:12

• Changed state: Started

[GoogleCodeExporter]

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.

Original comment by widdis@gmail.com on 23 Nov 2011 at 5:28

• Changed state: New

[GoogleCodeExporter]

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.

Original comment by widdis@gmail.com on 24 Nov 2011 at 9:29

• Changed state: Fixed