Issue 156 in anomalyjobs: GOING rotation instead of timing
anoma...@googlecode.com
Owner: ----
New issue 156 by lasht...@gmail.com: GOING rotation instead of timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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.
anoma...@googlecode.com
Labels: Type-Enhancement Priority-Low Milestone-Release6.5 Usability
Comment #1 on issue 156 by widdis: GOING rotation instead of timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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....
anoma...@googlecode.com
Comment #2 on issue 156 by lasht...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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).
anoma...@googlecode.com
Comment #3 on issue 156 by Fleety...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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.
anoma...@googlecode.com
Comment #4 on issue 156 by lasht...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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.
anoma...@googlecode.com
Comment #5 on issue 156 by Fleety...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
[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. ;)
anoma...@googlecode.com
Comment #6 on issue 156 by ke...@writh.net: GOING rotation instead of timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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.
anoma...@googlecode.com
Comment #7 on issue 156 by Fleety...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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?
anoma...@googlecode.com
Comment #8 on issue 156 by Fleety...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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.
anoma...@googlecode.com
Comment #9 on issue 156 by ke...@writh.net: GOING rotation instead of timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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.
anoma...@googlecode.com
Comment #10 on issue 156 by Fleety...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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.
anoma...@googlecode.com
Comment #11 on issue 156 by ke...@writh.net: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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. :)
anoma...@googlecode.com
Status: Accepted
Labels: -Type-Enhancement Type-Other Component-Docs
Comment #12 on issue 156 by wid...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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. :)
anoma...@googlecode.com
Status: Fixed
Comment #13 on issue 156 by wid...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
Added to the HOWTO in r412. And killed references to the GOING flag in
r411.
anoma...@googlecode.com
Status: Started
Labels: -Milestone-Release6.5 Milestone-Release6.6
Comment #14 on issue 156 by wid...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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.
anoma...@googlecode.com
Comment #15 on issue 156 by wid...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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;
anoma...@googlecode.com
Comment #16 on issue 156 by wid...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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
anoma...@googlecode.com
Comment #17 on issue 156 by wid...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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.
anoma...@googlecode.com
Comment #18 on issue 156 by wid...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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.
anoma...@googlecode.com
Comment #19 on issue 156 by wid...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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. :)
anoma...@googlecode.com
Comment #20 on issue 156 by Fleety...@gmail.com: GOING rotation instead of
timing
http://code.google.com/p/anomalyjobs/issues/detail?id=156
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.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings