Anomaly Jobs: +myjob/cc

[Thenomain]

I am using extended code for Anomaly Jobs that creates a switch, +myjob/cc and +job/cc. It adds more people to the 'opened by' list.

However, I didn't patch it from source. Instead, I grabbed the core command code from another game. Because of this, I am getting unexpected behavior. Mainly, if one person on the 'opened by' list uses +myjob/add, the comment cannot be read by anyone else on the job except staff.

Who coded this and where can I get the complete patch from?

Thanks.

(explanation of the issue: +myjob/add does not publish comments. Instead, the part of aJobs that determines whether or not a comment is published sees that the person who made the comment is the same person who opened the job, and considers that comment published. That is, it's logically-publsihed instead of set-as-published. When you have multiple people on the 'opened by' attribute on the job, the logic which determines which comments are published fails, and people can only see their own.

I am not looking for ideas on where I can patch this up. I know where I can, but I want the original code so I can do it in the expected manner.)

[Alzie]

@Thenomain Reason: You don't set the comment inherit. By default, setting people on the opened by doesn't mean that they can see each other's comments, this is intended behavior - at least for the developers of anomaly jobs. So if you want the whole job to be visible to everyone you either set all the comments Inherit or you set the PUBLISH attribute to 1 on the job object that is created when the job is opened.

If you want, I have a myjob/publish command.

[Thenomain]

@Alzie

this is intended behavior - at least for the developers of anomaly jobs

That's awesome, but whomever created +myjob/cc should know this, as it works well enough around in the other games. As I didn't install it from base, I'm missing something.

I know what I can do. I already mentioned that. I'm funny that I'd like to do what the code creators expect, in case it has to be maintained by someone who's not me later on.

[Alzie]

@Thenomain said:

@Alzie

this is intended behavior - at least for the developers of anomaly jobs

That's awesome, but whomever created +myjob/cc should know this, as it works well enough around in the other games. As I didn't install it from base, I'm missing something.

I know what I can do. I already mentioned that. I'm funny that I'd like to do what the code creators expect, in case it has to be maintained by someone who's not me later on.

You aren't missing anything. Myjob/cc doesn't do anything to make it so other players can see the comments of anyone else on the job. How you do that is explained above. This is Myjob/cc:

$+myjob/cc *=*:@switch [not(u(%va/FN_GUEST,%#))][setq(0,u(%va/FN_FIND-JOB,%0))][isdbref(%q0)][or(and(u(%va/IS_PUBLIC,%q0),match(get(%q0/OPENED_BY),%#)),u(%va/FN_MYACCESSCHECK,parent(%q0),%#,%q0),)][not(u(%va/FN_HASATTR,%q0,LOCKED))][setq(1,map(%va/MAP_SOURCE,secure(trim(%1))))][setq(2,member(%q1,#-1))][not(gt(%q2,0))]=0*,@pemit %#=This command is not available to guests.,10*,@pemit %#=That is an invalid job number.,110*,@pemit %#=[name(%q0)] is not yours. You can only modify your own jobs.,1110*,@pemit %#=That job is locked and cannot be changed at this time.,11110*,{@pemit %#='[extract(secure(trim(%1)),%q2,1)]' is not a valid player or jgroup.},{&opened_by %q0=[setunion(get(%q0/opened_by),%q1)];@pemit %#=You have set job #%0 to have a source of [u(%va/FN_PLAYERLIST,%q0)].;&JOBACCESS %q0=[ifelse(member(get(%q0/JOBACCESS),u(%va/FN_OBJID,%q1)),remove(get(%q0/JOBACCESS),u(%va/FN_OBJID,%q1)),setunion(get(%q0/JOBACCESS),u(%va/FN_OBJID,%q1)))];@trigger %va/TRIG_ADD=%q0,Source changed to [u(%va/FN_PLAYERLIST,%q0)].,%#,SRC;@trigger %va/TRIG_BROADCAST=%q0,%#,SRC,%q1;@pemit [pmatch(%1)]=You have been CC'ed to Job %0.}

The only thing it does is add people to the job access list, which lets you use commands on the job.

Also, apology, the flag is no_inherit, not inherit.

If you're saying 'Alzie, I don't want to do it the easy way, tell me the hard way' then your answer is FIL_PUBLISHED, FIL_COMMENTS, FN_MYACCESSCHECK on the Job Database and CMD_MYJOB/VIEW on Job Global Object. Have fun.

FIL_PUBLISHED - Tells the system which comments the person sees
FN_MYACCESSCHECK - A function used by FIL_PUBLISHED to check whether or not a person has access to the comment
FIL_COMMENTS - Determines which of the final list of comments is shown based on what comment types should be visible

[Thenomain]

@Alzie said:

There is no source for this code. Therefore, it is shit.

Just making sure we're on the same page, here.

[Alzie]

@Thenomain said:

@Alzie said:

There is no source for this code. Therefore, it is shit.

Just making sure we're on the same page, here.

I'm not sure what that's about, but I gave you the full copy of myjob/cc above. In any case, I've said all I have to say about it and given you all the information you need to go forward.

Also: https://code.google.com/p/anomalyjobs/source/detail?r=427

[Thenomain]

@Alzie said:

I'm not sure what that's about, but I gave you the full copy of myjob/cc above. In any case, I've said all I have to say about it and given you all the information you need to go forward.

Because:

@Thenomain said:

I am not looking for ideas on where I can patch this up. I know where I can, but I want the original code so I can do it in the expected manner.

@Thenomain said:

I know what I can do. I already mentioned that.

I was being an eternal optimist thinking that the behavior was not complete and it was me who was missing something. Best I can tell is you're telling me that this code is working exactly as it was designed.

If so, it's shitty design.

I'm sorry if it's yours and I'm insulting it, but if you 'cc' someone on a job, then I think it's pretty useless if people are not seeing the same job. 'bcc' would be a more appropriate switch in that case.

I do generally get frustrated when I implement someone else's half-assed code. Even if it's my half-assed code.

Yeah, anyway, done. I'll be completing this broken code when I can.

[Alzie]

@Thenomain Oh, no, I didn't make it. It was added by the anomaly jobs people. This is the original source. I also think it's a little silly, but I understand why it was left, it's sometimes not desirable, especially on our game when we do status votes.

https://code.google.com/p/anomalyjobs/source/browse/trunk/full/jobs-full.txt#2032

[Cobalt]

I made it. Well very likely the version you're using. Either that or potentially @Loki or @chime. And this bug is one that happened after AnomJobs V5, I think? The original +myjob/cc I made for DW worked fine, however after the code changes to the latest version of AnomJobs the outdated +myjob/cc apparently got broken.

I think I fixed it recently on Reno, and may have informed someone how to fix it but I can't remember who.

Oh! HR, that's right. @HelloRaptor and I recently discussed the issues with it. Here's what I ended up doing on DW to patch it:

TRIG_MYADD: think [setq(0,default(%0/NUM_COMMENT,1))][setq(1,last(grab(get(%0/LIST_JOBSN),%2|*),|))][setq(2,edit(%1,|,@@PIPE@@))][ifelse(eq(dec(%q0),%q1), set(%0,LIST_JOBSN:[setunion(remove(get(%0/LIST_JOBSN),%2|%q1),%2|%q0)]),)][ulocal(FN_ADDSTAT,%3,%va)][ulocal(FN_ADDSTAT,%3,%0)][ulocal(FN_ADDSTAT,%3, parent(%0))];&COMMENT_%q0 %0=%3|[secs()]|%2|[name(%2)] [ifelse(u(%va/FN_HASATTRP,parent(%0),ALETTER_%3),u(%va/FN_STRTRUNC,u([parent(%0)]/ALETTER_%3,%0,%2,%q2),get(%va/BUFFER)),u(%va/FN_STRTRUNC,%q2,get(%va/BUFFER)))];&NUM_COMMENT %0=[inc(%q0)];&MODIFIED_ON %0=[secs()];&MODIFIED_BY %0=%2;@trigger parent(%0)/HOOK_%3=%0,%2,[parent(%0)],%1;@trigger %va/TRIG_POST=%0,%3,%2,%1;@trigger %va/TRIG_MAIL=%0,%3,%2,%1;@set %0/comment_%q0=no_inherit

Onto the JD.

And then changed +myjob/add on the jgo to trigger trig_myadd, instead of trig_add.

---

This is what I came up with at the time because of the way trig_add works. I think the issue I ran into was if I didn't do it that way, then the entire job would be revealed -- even staff comments. I might be able to come up with something better sometime, nebulously, in the future ...

But anomjobs is a mess. The way comments are made is infuriating to poke at.

[Groth]

Just keep in mind your solution means all +myjob/add comments are published which may or may not be desired behaviour. /add comments are unpublished by design and it's not a shitty design, there exist no reason to expect that all comments to a job are readable by all people involved and changing this behaviour makes it useless for certain tasks such as anonymous voting, conflict resolution etc.

The cleanest solution here is most likely to have +myjob/cc publish the job as well as change &FIL_PUBLISHED to not display comments from staff unless they also have the no_inherit flag.

&CMD_MYJOB/CC [v(JOB_GO)]=$+myjob/cc *=*:@switch [not(u(%va/FN_GUEST,%#))][setq(0,u(%va/FN_FIND-JOB,%0))][isdbref(%q0)][or(and(u(%va/IS_PUBLIC,%q0),match(get(%q0/OPENED_BY),%#)),u(%va/FN_MYACCESSCHECK,parent(%q0),%#,%q0),)][not(u(%va/FN_HASATTR,%q0,LOCKED))][setq(1,map(%va/MAP_SOURCE,secure(trim(%1))))][setq(2,member(%q1,#-1))][not(gt(%q2,0))]=0*,@pemit %#=This command is not available to guests.,10*,@pemit %#=That is an invalid job number.,110*,@pemit %#=[name(%q0)] is not yours. You can only modify your own jobs.,1110*,@pemit %#=That job is locked and cannot be changed at this time.,11110*,{@pemit %#='[extract(secure(trim(%1)),%q2,1)]' is not a valid player or jgroup.},{&PUBLISH %q0=1;&opened_by %q0=[setunion(get(%q0/opened_by),%q1)];@pemit %#=You have set job #%0 to have a source of [u(%va/FN_PLAYERLIST,%q0)].;@trigger %va/TRIG_ADD=%q0,Source changed to [u(%va/FN_PLAYERLIST,%q0)].,%#,SRC;@trigger %va/TRIG_BROADCAST=%q0,%#,SRC,%q1}

Used MAIL_ACCESS as the staff check, replace with whatever you feel is appropriate.

&FIL_PUBLISHED [v(JOB_VA)]=or(and(u(%q0/PUBLISH),not(u(%va/MAIL_ACCESS,extract(get(%q0/%0),3,1,|)))),hasflag(%q0/%0,no_inherit),u(%va/FN_MYACCESSCHECK,parent(%q0),%#,%q0),t(member(u(%q0/OPENED_BY),extract(get(%q0/%0),3,1,|))),strmatch(extract(get(%q0/%0),3,1,|),%#))

Tangentially, using the numbers 0-4 as your variable names should count as a crime against humanity.

[Chime]

@Groth It's written to be portable mushcode, and very old. Hence, numeric registers.

Though really, all mushcode is pretty awful.

[Cobalt]

@Groth said:

Just keep in mind your solution means all +myjob/add comments are published which may or may not be desired behaviour.

Yes, I'm aware of that fact. I had coded up a +myjob/padd (private-add) that allowed people to post to a multi-user job privately.

However, I agree with Thenomain on the poor design of it. 'cc' means it should be visible to everyone. Frankly, you shouldn't be using +jobs/+myjobs for anonymous voting. If you want that you should probably code a +vote system that allows for actual anonymous voting. +myjobs doesn't do that very well. Frankly, there's too much visibility.

"Staff can see who voted what", btw, is not anonymous voting.

[Thenomain]

As I said, if expected behavior was to have each person's comments hidden, then the accepted nomenclature for this is 'bcc'. Accepted as in older than aJobs or even Mud.

I shan't be publishing the entire job because staff still want to discuss things behind the scene, and it would disrupt their expected behavior as well.

Which is my gripe. It's about expected behavior. My expectations, it would seem, but I'm working on some five or so complaints that they can't see comments made by others. My best guess is because what "cc" means to the majority of end users.

Hence the "bcc" recommendation.

My venting about it is mostly because dealing with undocumented code is not fun on the best of days. Working out what aJobs is intending is a job in itself. It does a few beautiful things, but on the whole I dread even thinking about it.

I'll dial it back, tho, since this is now a discussion.

[Chime]

@Thenomain said:

As I said, if expected behavior was to have each person's comments hidden, then the accepted nomenclature for this is 'bcc'. Accepted as in older than aJobs or even Mud.

Even the earliest mailspec I could find (okay, without looking very hard), RFC 733:

               STANDARD FOR THE FORMAT OF

              ARPA NETWORK TEXT MESSAGES(1)




                    21 November 1977

Has mention of bcc with the traditional semantics in section IV: Semantics, subsection B: Reference Specification Fields, heading 3: Receiver fields, item b. This was a codification of much earlier mail semantics from early arpanet days, likely dating back to research from circa 1965.

That said, cc stands for carbon-copy, and so bcc is blind carbon copy, and I believe both were in use within business and governmental offices in at least the US by the 1940s. I don't have a citation for that though-- and I suspect one of those hideous style manuals would be a better place to track the origins of the term.

[Chime]

Interestingly, several people found this odd tangent as interesting as I did and informed me of the usage "blank" carbon-copy; I'm still not sure which is most prevalent, but both blank and blind carbon-copy do appear to be used and used interchangeably.

Per Wikipedia, "Ralph Wedgwood obtained the first patent for carbon paper in 1806."

So. I guess we can celebrate 209 years of cc and bcc, at least as used for office political shenanigans.

[Thenomain]

Best tangent yet. I tried to track down when bcc became a thing, but after 20 minutes gave up.

I'm probably going to change how the "is this published?" code works, but there is no optimal way to do it. If you're on 'opened_by', you're published.

Except... No. If on opened_by but not staff? I could add the function to +myjob/add, but even that feels like a kludge.

Where in this mess do you guys think would be the best place to add this functionality? Publishing the entire job is right out.

[Misadventure]

Blank CC works best when using a manual typewriter with actual carbon paper and the recipients of the bcc are unknown to the primary and secondary recipients. There were issues with people being able to read the letter impressions of other recipients.

Blind CC, or more exactly Blind Copy would well on a digital system.

So I vote for /add and /bc.

Might be awesome to be able to add a private comment as a player, so only staff can see that.
Uber special would be only viewable by highest ranked staff, aka the sphere Wizard, or Headstaff etc.

[Groth]

@Thenomain said:

Best tangent yet. I tried to track down when bcc became a thing, but after 20 minutes gave up.

I'm probably going to change how the "is this published?" code works, but there is no optimal way to do it. If you're on 'opened_by', you're published.

Except... No. If on opened_by but not staff? I could add the function to +myjob/add, but even that feels like a kludge.

Where in this mess do you guys think would be the best place to add this functionality? Publishing the entire job is right out.

I posted code that alters +publish so that it no longer displays comments added by staff unless manually published on a by comment basis. As pointed out by Alzie you just alter FIL_PUBLISHED.

[Derp]

@Misadventure said:

Might be awesome to be able to add a private comment as a player, so only staff can see that.

The problem I see with this is that there would be no way to reply to just that one player's comment in the job without additional systems.

[Misadventure]

BUT it might be really really useful.