+myjobs problems

[GoogleCodeExporter]

Tested +myjobs implementation.  r225/r226 apply.  Following issues still
outstanding:

1. +myjob/create only tests bucket access (PUBLIC) for creation.  In short,
I can create a job in any bucket that I can read.  This effectively
bypasses the checks in +job/create for CREATE_ACCESS.  You need a separate
MYJOB_CREATE permission. See Issue 21, comment 6.  Fixing this will affect
most of the commands, as well.

2. +mybuckets header doesn't match contents.  Header shows "NAME   
Description" but then contents are the full bucket list including
visibility, jobs in the bucket, boards, turnaround, ARTS, etc.  

3. +myjob/help <#> returns empty header and footer if there is no myjob
help.  Unlike +job/help, you can't just stick a default help attribute on
the parent, because then it would also show up in +job/help.  Either
+myjob/help or +job/help needs to explicitly test for attribute presence
and present an appropriate message.

4. We should *consider* recoding +pitch to simply alias the appropriate
+myjob command, e.g., 

&CMD_+PITCH JGO=$+pitch *=*:@fo %#=+myjob/create PITCH/%0=%1 (and an
appropriate emit to player)

This would serve as a template for games that wanted to create their own
similar feature such as the +build command mentioned in issue 21. 

You could also do similar for +request, +typo, and +bug, except that the
current commands also set priority, and that switch is not available on
+myjob/create. 

Original issue reported on code.google.com by widdis@gmail.com on 16 Jan 2010 at 12:26

[GoogleCodeExporter]

On second thought, scratch 4. There's really no reason to @force +myjobs rather 
than
just triggering TRIG_CREATE as the commands do now.

Original comment by widdis@gmail.com on 16 Jan 2010 at 12:32

[GoogleCodeExporter]

OK, on third thought, I'm wondering about the whole need for +myjob/create in 
the
first place.  It creates more problems than it solves (requires extra 
permissions,
requires +mybuckets, requires separate help and gymnastics to properly display
defaults, and limits what can be set on the initial job compared to trig_create 
 ...
in sum, the entire list of problems in this issue) and probably won't be used 
much
anyway. (It's hard enough to get half the staff to learn the +jobs commands.)

+build, along with other customized +request/bucket-type commands can be much 
more
easily done with @trig_create than by forcing a (more limited) +myjob/create.  

Sorry for the extra work, Fleety419, but I'm thinking we nix the +myjob/create,
+myjob/help, and +mybuckets commands, and just stick with the other mods 
(skinning,
headers, etc.)

Original comment by widdis@gmail.com on 16 Jan 2010 at 1:14

[GoogleCodeExporter]

This has been another 'bite the bullet' issues that I'm not a fan of.

I'm for getting rid of it.

Original comment by Fleety...@gmail.com on 16 Jan 2010 at 9:39

[GoogleCodeExporter]

+myjob/create and +mybuckets are gone.

I left +myjob/help in there for now as it's a separate issue.  If you want to 
keep it
in there you need to address default for an empty attribute per point 3 of the 
OP.

Original comment by widdis@gmail.com on 17 Jan 2010 at 1:27

[GoogleCodeExporter]

Fixed in r236.

Original comment by widdis@gmail.com on 18 Jan 2010 at 7:02

• Changed state: Fixed