GOING rotation instead of timing

[GoogleCodeExporter]

Currently, when you approve/deny/complete a job and it's scheduled for removal, 
it goes to the GOING bucket and is removed after a (small) period of time.

What if, instead, N jobs were kept in GOING and each additional job removal 
kicked out the oldest going job (by order of insertion, not job number).

This would ensure that you could always view the last N closed jobs.

This might be doable from a trigger, but seems like useful behavior for 
everyone.

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

[GoogleCodeExporter]

This is an interesting idea.  One complicating factor is that the various 
codebases treat @destroyed objects differently so we're already introducing 
some complexity for what's supposed to be a simple "trash this job" feature.

Let me think on it.  It might just be something to document in one of the text 
files for advanced users....

Original comment by widdis@gmail.com on 30 Jun 2011 at 3:38

• Added labels: Type-Enhancement, Priority-Low, Milestone-Release6.5, Usability

[GoogleCodeExporter]

Right.  It'd probably mean having a real GOING bucket and not @destroying 
things until they're ready to be kicked out of that.  Can't portably rely on 
@destroyed things hanging around usefully.

This also means that having another command to forcibly sweep out GOING objects 
would be useful (For when jobs are overflowing again).

Original comment by lasht...@gmail.com on 30 Jun 2011 at 4:22

[GoogleCodeExporter]

I don't think that this should be the default behavior, myself. Pop and push 
from a garbage stack doesn't seem of much use to the general population, 
especially since there are already mechanisms in place for archival. 
Considering that
a discussion is underway about lbuf and attribute size, this adds to unnecessary
object bloat by keeping unneeded objects around. It's best accomplished 
game-side 
using some of the triggering features for people who want the behavior.

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

[GoogleCodeExporter]

Archival doesn't address this, typically, without a way to completely re-create 
the job state from an archived job.  Typical use-case we see:

JOBS: Job nnn has been approved by A.
[WizChat] A says, "Uh.  hm.  Shit shit shit."
[WizChat] A says, "Anyone remember how to undo things? I approved the wrong 
job.  Again."

Invariably they remember or are told after it's long-gone.  Our archive allows 
retrieval and rebuilding, manually, so there is always a work around, but it's 
cumbersome.  Sometimes it's just nice to review the job that's closing, if 
appropriate.

The jobs db filling issue (158) isn't directly in conflict with this.  A 
garbage queue of even 2 objects would make a HUGE difference in terms of 
usability and not have a very large impact on total job count.

Original comment by lasht...@gmail.com on 3 Jul 2011 at 3:12

[GoogleCodeExporter]

[WizChat] A says, "Anyone remember how to undo things? I approved the wrong 
job.  Again."

Sounds like you need a special lock to keep Wizard A away from 
/complete/approve/deny. ;)

Original comment by Fleety...@gmail.com on 3 Jul 2011 at 4:13

[GoogleCodeExporter]

Except it's a very common occurence when you have over 500 jobs.  We probably 
see this happen once a month, and it's most of staff.  To note, this also 
happens in big industry using very expensive ticket management software, too. 
This problem cannot be waived away, but it also isn't THAT big a hurdle, either.

I do think this can probably be handled with a series of hooks, though.  
Basically, move the current GOING behaviour out of the main JGO, and put it on 
a HOOK on the GOING bucket.  Then it won't be overwritten during upgrades, and 
can be modified to suit preference.

Original comment by kkragenb...@gmail.com on 3 Jul 2011 at 5:32

[GoogleCodeExporter]

There is no actual GOING bucket; it does not physically exist. The GOING bucket 
is merely a textual state based on whether or not the job has been set GOING; 
no other change is really made to a job that has been deleted (except an 
attribute getting set called GOING, as well). Let's call our new bucket RAR 
(rescue and review).

&HOOK_COM <JDO>=@set %0=!going;&GOING %0=;@fo %#=+job/trans 
[last(name(%0))]=RAR Bucket;@switch [words(lcon(Rar Bucket))]=6,{@nuke 
first(lcon(RAR Bucket))},{@@}

Quick and dirty (and wholly untested), but you should get the idea. Make an 
identical hook for the approval, deny and delete commands, and you've got 
yourself a pop and push garbage stack.

These are the kinds of 'specialty' applications for which we envisioned action 
hooks. 

Can we include this one (or, rather, one like it that has been debugged and 
tested) in our HOWTO document?

Original comment by Fleety...@gmail.com on 4 Jul 2011 at 4:11

[GoogleCodeExporter]

The clearing of the &GOING attribute causes the job to not be found by the 
FIL_GOING filter. Thus, setting the object !going and transferring it to the 
new review/recovery bucket would be enough object-tinkering to accomplish what 
is necessary for this application.

Original comment by Fleety...@gmail.com on 4 Jul 2011 at 4:57

[GoogleCodeExporter]

The only downside to this is that it a) does a forced +job/trans, thus more 
spam and more bucket stats than are strictly necessary.  Would be nice to find 
a non-/trans alternative to that. That said, I like how very simple that was to 
achieve. Nicely done, Fleety.

Original comment by kkragenb...@gmail.com on 5 Jul 2011 at 4:10

[GoogleCodeExporter]

Thanks, but I made quite a few errors up there. The hook needs to be on the 
Bucket Parent, the &GOING attr does indeed need to be removed, there is no lcon 
for a bucket (only children). So take my advice as suggestion, and not 
expertise. Widdis is far better at the nuts and bolts than I am at this point; 
he's practically rewritten jobs (and in a far superior image). I'm just the guy 
that sits around and is impressed that people get good use out of the system 
while offering dinosaur commentary.

That said, I whipped one up and tested it, and it works like a charm. It does 
not use /trans but you need to know the database # of your Review/Recover 
bucket <RAR>. It's also assuming you want 5 jobs to keep, but just replace the 
5 with a number of your choice.

&HOOK_APR <Bucket Parent>=@set %0=!going;&GOING %0=;@parent %0=<RAR>;@switch 
gt(words(children(<RAR>)),5)=1,{@nuke [first(children(<RAR>))];&GOING 
[first(children(<RAR>))]=1}

Make an identical one for HOOK_COM, HOOK_DNY, and HOOK_DEL, and there is a 
garbage stack, just waiting to pop at the next push.

Original comment by Fleety...@gmail.com on 5 Jul 2011 at 11:30

[GoogleCodeExporter]

Nicely done, sir.  I think I will implement this in short order on HM; just 
gotta figure out where to put it in the archival cycle HM has.  We archive to 
MySQL forums. :)

Original comment by kkragenb...@gmail.com on 6 Jul 2011 at 12:18

[GoogleCodeExporter]

I'll add this to the HOWTO document.  Since the desired functionality is there, 
I'm not changing the code.

Actually, I might change the code.  The GOING flag is no longer used at all by 
the code, only the job's GOING attribute.  There are some residual/legacy set 
%0=!going calls in +job/trans and +job/undelete that are wholly unnecessary and 
should be removed.  And it's not needed in the above hook, either. :)

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

• Changed state: Accepted
• Added labels: Type-Other, Component-Docs
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

Added to the HOWTO in r412.  And killed references to the GOING flag in r411.

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

• Changed state: Fixed

[GoogleCodeExporter]

So I thought this was a good idea and went to implement it on my game.  
Unfortunately I found a flaw:  children() sorts in dbref order so 
first(children()) will delete the lowest numbered dbref'd job rather than the 
last deleted one.

To really make this work right, you'd need to have the hook timestamp the job 
and sortby (or sortkey on Penn) to get the oldest one.  Or you can compare 
mtime()s, possibly.

Original comment by widdis@gmail.com on 29 Nov 2011 at 3:04

• Changed state: Started
• Added labels: Milestone-Release6.6
• Removed labels: Milestone-Release6.5

[GoogleCodeExporter]

Actually, the timestamp's already there (Thanks Fleety) with the modified_on 
attribute.  Here's my implementation in PennMUSH, using the attribute sort 
type.  #6561 is my TRASH bucket.

&HOOK_APR Job Parent Object=
    &GOING %0;
    @parent %0=#6561;
    @assert gt(words(children(#6561)),5);
    &GOING [setr(0,first(sort(children(#6561),attr:modified_on)))]=1;
    @nuke %q0;

Original comment by widdis@gmail.com on 29 Nov 2011 at 3:41

[GoogleCodeExporter]

For platform compat-ness:
- sort() would be a sortby(%va/SORTBY_DATE,children()
- @assert back to the ugly @switch 
- @nuke to appropriate server's @destroy alias

Original comment by widdis@gmail.com on 29 Nov 2011 at 3:57

[GoogleCodeExporter]

Last comment and I promise to stop spamming.  Should add a note about 
permissions:  TRASH should be locked to only players who can view all the other 
jobs.

Original comment by widdis@gmail.com on 29 Nov 2011 at 4:04

[GoogleCodeExporter]

OK, so not the last comment.  As it is above, the hook is being triggered 
(changing the parent) before the other job completion triggers (mailing 
MLETTERs, posting ALETTERs, and broadcasting BLETTERs.)  

An @wait of a few seconds should fix things.

Original comment by widdis@gmail.com on 29 Nov 2011 at 4:14

[GoogleCodeExporter]

A few more comments, after actual implementation of this.
- The children() call doesn't work because the hook is executed by the job, 
which doesn't have permissions.  I had to work around it with a FUN_CHILDREN on 
the job database object.
- despite the staff being told to +bucket/monitor TRASH to turn it off, at 
least one staffer didn't.  And even with monitor off on the TRASH bucket, it 
displays in +jobs/overdue, +jobs/date, and other displays.  Might have to 
include jobs in the trash bucket in the FIL_GOING call.

This is starting to look more and more like a plugin and less like a HOWTO 
article. :)

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

[GoogleCodeExporter]

An idea:

What if the GOING attribute was a timestamp instead of '1', which basically 
says 'after this timestamp, it is okay to delete this job'. A game could set 
their GOING to be however many hours they want to keep the job in the 
'archive', which would alleviate-but-not-solve the fumble-finger problem.

Original comment by Fleety...@gmail.com on 2 Apr 2013 at 6:50