depwl9992 / anomalyjobs

Automatically exported from code.google.com/p/anomalyjobs
0 stars 0 forks source link

+jobs/catchup alteration #137

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
+jobs/catchup presently uses the "Readers" attribute.  While this is fine for 
most setup, it removes a very important part of staff administration: auditing 
for staff reading jobs they should not be.

If possible, the JOBSN=1 setting should utilize a different attribute, set when 
you read and when you +jobs/catchup, which is used to determine newness.  This 
creates an unfortunate duplication of attributes; however, it also makes audit 
trails possible again, which is important on some games where staff behaviour 
is heavily scrutinised (World of Darkness and Shadowrun games, especially)

Original issue reported on code.google.com by kkragenb...@gmail.com on 13 Dec 2010 at 11:11

GoogleCodeExporter commented 9 years ago

Original comment by kkragenb...@gmail.com on 13 Dec 2010 at 11:11

GoogleCodeExporter commented 9 years ago
Alternative that I thought of: 

LIST_READERS: <dbref>|<last read>|<last caught up>

E.g. LIST_READERS: #123|0|19

In the above example, #123 will not show up on +job/summary because they have 
not read the job; however, job #123 will not show as 'new' unless it has 
comments > 19.

Original comment by kkragenb...@gmail.com on 13 Dec 2010 at 11:14

GoogleCodeExporter commented 9 years ago
I like that second option.  I can edit FN_READERS to take an argument if it's a 
"catchup". Which commands should trigger an "actual" read of the job?

+job <#>
+job/last
and the +myjob equivalents.

any others?  

Original comment by widdis@gmail.com on 13 Dec 2010 at 11:42

GoogleCodeExporter commented 9 years ago
Easier to separate the attributes than to parse one.  Included +job/all and 
+job/new to the above.  

Fixed in r377.

Original comment by widdis@gmail.com on 14 Dec 2010 at 12:05