Help with buckets and access

[GoogleCodeExporter]

I apologize, there wasn't an option for 'support' or 'other' in the drop down 
menu.

I'm actually seeing help on how to make my TPS bucket useable and viewable to 
people with the Guildmaster tag. I don't want them to have access to all of 
+jobs, just that bucket. This is so that, as "feature" characters" they can 
keep track of the prps and such they need to run. Or plots staff hands them.

So far the only way I've been able to do this is to give them architect (bit 
level 3 in rhost) assign the job to them and then downgrade them to Guildmaster 
(bit level 2 in Rhost)

I've tried defining a new fn_staffall2 attribute that compares with bit level 
2, but that didn't work.

Any help you can provide would be most appreciated.

Original issue reported on code.google.com by K.Jisa...@gmail.com on 19 May 2014 at 6:43

[GoogleCodeExporter]

Ok, I'm not familiar with Rhost, or the specific bit levels or their titles, 
but what you're wanting is pretty simple. You do not need to add them to the 
FN_STAFFALL function (and you should roll back to the old FN_STAFFALL instead 
of using your #2 version). The 'access' and 'baccess' portions of the help file 
describe how the access permissions need to be set.

First, anyone who needs to access the system via +jobs (as opposed to 
'+myjobs') must pass Job Database <JD>/HAS_ACCESS. That allows them to access 
the system with '+jobs' instead of '+myjobs'.

Then the bucket must be set so that they can get into it. That's set at the 
bucket level:

&ACCESS <TPS bucket DB#>=<your function which should return 0 for forbidden or 
1 for access>.

You would then need to go through and make sure that the other buckets forbid 
Guildmasters from seeing them. Make a test Guildmaster, log in and type 
'+buckets'. If they have access to more than just the TPS bucket, then you'd 
need to forbid those buckets.

That should accomplish what you're looking for, but if not, let us know.

Original comment by Fleety...@gmail.com on 19 May 2014 at 9:48

• Added labels: Type-Task
• Removed labels: Type-Defect

[GoogleCodeExporter]

One more note: if you do not add the level 2 bit to the FN_STAFFALL, you will 
need to decide what commands to give them access to (that list of *_ACCESS 
locks in the 'access' portion of the help file). Since they are features and 
not staff, you will probably not want them to have GIVE_ACCESS, for instance, 
but you'd probably want them to have ADD_ACCESS and CREATE_ACCESS, etc.

Leaving this ticket open for a few days; if you need more help, don't hesitate 
to ask.

Original comment by Fleety...@gmail.com on 19 May 2014 at 10:01

• Changed state: Completed

[GoogleCodeExporter]

I'm sorry, I still can't figure this out. I don't want guildmasters to have 
+job access. +myjobs is fine. I do want them to be able to create jobs into 
that bucket and have access to it.  

Also, I know you are unfamiliar with Rhost, it does not possess the builder 
power which is listed in Has_access.

Original comment by K.Jisa...@gmail.com on 22 May 2014 at 7:11

[GoogleCodeExporter]

Unfortunately, to do what you want to do, +job access is needed.  The +myjobs 
code is very specifically coded to only an individual's jobs, and is not easily 
extended to a bucket system.  However, just having access to the "+jobs" 
command does not mean access to all jobs everywhere.  It's just the command.  
Access to individual jobs can be controlled by which bucket they are in.

To reiterate/rephrase what you need to do, there are three steps:
1. Establish any softcode function to identify a guildmaster.  This can be 
bit-based, tag-based, lookup by DBREF, or whatever.  Just make a function where 
isGuildmaster(%0) returns "1" for someone you want to have access, and "0" for 
everyone else.
2. Make sure your bucket access does not allow guildmasters for all buckets 
except TPS.   You will find the individual bucket objects and add/edit the 
&ACCESS attribute on them (or let them inherit from a parent).  This is your 
normal isStaff() function or whatnot.  Then, for the TPS bucket, you would do 
something like &ACCESS TPS=or(isstaff(%0),isGuildmaster(%0))
3. Change the HAS_ACCESS attribute on the Job Database <JD> to permit the 
Guildmasters access to the +jobs commands. When they list jobs, they will only 
see jobs in buckets they have permissions to.  The only evidence they will have 
that any other jobs exist is in the numbering sequence.

Feel free to contact me via Google Chat (widdis@gmail.com) and I can join you 
on your game to help you implement this.

Original comment by widdis@gmail.com on 22 May 2014 at 7:24

[GoogleCodeExporter]

There is an alternate way to do what you want with hooks:

You could create a +tp/create command which triggers the job creation code for 
the TPS bucket (see the code and HOWTO document for TRIG_APPLY and modify 
appropriately), and then adds all the guildmasters to the job after it's 
created.  This MIGHT do what you need, but I'm not sure exactly what you need.

Original comment by widdis@gmail.com on 22 May 2014 at 7:29

[GoogleCodeExporter]

Is it a glitch, that with all code as default, no modifications. that if you do 
+bucket/access <player>=<bucket>

that it denies them access of both +jobs and +myjobs?  I experienced this just 
now. I removed &jobsb from the players and everything worked again.

Original comment by K.Jisa...@gmail.com on 22 May 2014 at 8:33

[GoogleCodeExporter]

That is not a glitch, it is intended behavior:

If a player does not have access to jobs, return an error.

If a player has access to jobs and access to the bucket, take access away from 
that bucket.

If a player has access to jobs and does not have access to the bucket, give 
access to the bucket.

It's a way of allowing people in or out to individual buckets. For instance, 
you have a builder that is also a decent coder, you can +bucket/access 
BuilderGuy=Code and he now can participate in all code jobs.

Or say you have a staff member that doesn't want spoilers from the TPS bucket - 
you can take away the ability to see anything in the TPS bucket.

The behavior is toggled - so you can just re-do the command to flip the 
behavior.

Original comment by Fleety...@gmail.com on 22 May 2014 at 9:18

[GoogleCodeExporter]

OK. I think I'm getting closer. I've realized if I accidentally leave the last 
] off of has_access, then the code acts as I want it to for 
guildmasters...however, it throws off +jobs for higher staff. without the 
error, guildmasters can't +job/create into the bucket. 
[hasflag(%0,guildmaster)] doesn't seem to work in these locks. 

&HAS_ACCESS Job Database 
<JD>=[or(u(%va/isguildmaster,%0),u(%va/FN_STAFFALL,%0))]
&isguildmaster Job Database <JD>=[gte(bittype(%0),2)]

is there anyway to get a combination of both? I've put 
[hasflag(%0,guildmaster)] into all my access locks in the bucket but that 
doesn't seem to make much of a difference. I guess I'm  to be force to make a 
separate +tps command so they can create jobs.

Original comment by K.Jisa...@gmail.com on 22 May 2014 at 9:36

[GoogleCodeExporter]

Don't give up quite yet, you're almost there. Based on your code, Guildmasters 
can now see into the system via +jobs.

See, HAS_ACCESS only determines (essentially) whether you use +jobs or +myjobs 
to access the system. It doesn't grant very much 'extra' behavior.

Now you need to give Guildmasters the ability to interact with their jobs, and 
you'll need to figure out which +jobs commands the Guildmasters can perform:

     COMPLETE_ACCESS: Returns 1 if a player can /complete jobs.
     APPROVE_ACCESS:  Returns 1 if a player can /approve jobs.
     DENY_ACCESS:     Returns 1 if a player can /deny jobs.
     CREATE_ACCESS:   Returns 1 if a player can use the /create command.
     ADD_ACCESS:      Returns 1 if a player can use the /add command.
     GIVE_ACCESS:     Returns 1 if a player can use +bucket/access.
     EDIT_ACCCESS:    Returns 1 if a player can use the /edit command.
     STATS_ACCESS:    Returns 1 if a player can pull reports on the system.
     LOG_ACCESS:      Returns 1 if a player can /log a job.
     MAIL_ACCESS:     Returns 1 if a player can /query and /mail.

It sounds like they need 'CREATE_ACCESS, ADD_ACCESS, MAIL_ACCESS, 
COMPLETE_ACCESS'. They can create jobs, add info to them, mail people about 
them, and /complete them.

If you want to keep the original job from other players, you'd modify 
APPROVE_ACCESS instead of COMPLETE_ACCESS.

Add in your guildmaster check to those access checks, and it'll be doing 
exactly what you wanted it to do.

Rhost doesn't have the builder power, but following the builder logic is a good 
demonstration of how we approach letting a builder into the system by example. 
Builders on MUX and MUSH have fewer restrictions on quota, but otherwise they 
are normal players - the exact same scenario you're wanting out of your 
Guildmasters.

You're almost there.

Original comment by Fleety...@gmail.com on 22 May 2014 at 9:53

[GoogleCodeExporter]

Feel free to tag widdis and get him helping on-site like he offered - he knows 
his stuff (far better than I know mine), has been in charge of Jobs since 6.0, 
and is a Generally All-Around Good Guy.

Original comment by Fleety...@gmail.com on 22 May 2014 at 10:10

[GoogleCodeExporter]

So do I just need to remove the Create_access from the master object and define 
it individually per bucket? I defined it on the TPS bucket but nothing changed. 
Then I realized the master object has it set to the fn_staffall.

Original comment by K.Jisa...@gmail.com on 22 May 2014 at 10:14

[GoogleCodeExporter]

I think I see where the mistake is - don't set COMPLETE_ACCESS and such on the 
bucket, that's set at the same place HAS_ACCESS is.

&ACCESS on the TPS Bucket itself is the only lock on the bucket that 
Guildmasters need to pass.

Original comment by Fleety...@gmail.com on 22 May 2014 at 10:15

[GoogleCodeExporter]

Oh yeah, are your job objects still joining channels?

If not, how'd you fix it?

Original comment by Fleety...@gmail.com on 22 May 2014 at 10:27

[GoogleCodeExporter]

YAY! I seem to have figured it out. IF there is a *_access that is set on my 
parent object, it superceeds all *_access on the individual buckets. 

I redefined mail_access on parent object and got it to work. removed it from 
the parent and set it on the bucket and it worked. But I realize this would 
also leave all other buckets not otherwise defined unlocked.

So my guildmasters can use +tps to add a job (I'm fine with that), they can 
+job/mail, assign their jobs, add to their jobs,

I haven't fixed that. I have no idea how. They still show up randomly on 
channels.

Original comment by K.Jisa...@gmail.com on 22 May 2014 at 10:28

[GoogleCodeExporter]

Excellent on the first part.

Not excellent on the second part.

I've got a suspicion that it could be related to recycling. How intense is your 
'junk object' policy? Do you clear out old players regularly, and get rid of 
their trash? Does the new job have the same DB# as a player who was recently 
destroyed? The player's DB# could be getting set on Ashen's comsys somewhere 
(especially if it is a soft-coded system), and not getting un-set when the 
player is destroyed. When a new job comes along, the comsys thinks 'oh Bob is 
back' when Bob is really Job 65 now.

Original comment by Fleety...@gmail.com on 22 May 2014 at 10:40

[GoogleCodeExporter]

I go clear out fairly regular, for me at least. I have so little recycling till 
recently that I could go months without there being anything to get rid of. 
I've never paid attention.

I was just checking my channels. I have 3 jobs, all current jobs, that are 
showing on my newbie channel. So they must be old character db#. I'll keep an 
eye on this and let you know.

Original comment by K.Jisa...@gmail.com on 22 May 2014 at 10:48

[GoogleCodeExporter]

Regarding the first part: a parent object shouldn't "supercede" access on the 
child (the bucket).  I think the bucket isn't even looked at for the *_access 
attributes, per Fleety's comments 9 and 12.  

I think the jobs-on-channels issue is related to object creation, and something 
in Ashen's comsys that recognizes a new object.  Can anyone point me to the 
source code fo this comsys so I can look into it more?

Original comment by widdis@gmail.com on 22 May 2014 at 10:49

[GoogleCodeExporter]

All I know if If I have the same *_access on the bucket and parent...and if 
they are set differently, then the lock doesn't work...even if the one on the 
bucket is an easier lock

Original comment by K.Jisa...@gmail.com on 22 May 2014 at 10:51

[GoogleCodeExporter]

Yeah, I think that's the case indeed.

Here's AshCom v2, widdis:

https://rhostmush.googlecode.com/files/comsys

I can't find provision in it for an auto-cleanup from glancing at it, but it's 
assuredly saving DB#'s of players in it.

Original comment by Fleety...@gmail.com on 22 May 2014 at 10:59

[GoogleCodeExporter]

I'll play with the *_ACCESS locks on bucket/etc real fast and see if I can 
replicate on MUX.

Original comment by Fleety...@gmail.com on 22 May 2014 at 11:00

[GoogleCodeExporter]

I'm giving her all she's got, but I cannot replicate that problem in MUX, 
captain.

Original comment by Fleety...@gmail.com on 22 May 2014 at 11:06

[GoogleCodeExporter]

That's alright. It may be a rhost thing. But it works. My racial buckets are 
locked to rpflags. But I was able to give guildmaster +bucket/access..so 
everything is good at the moment. The only odd thing is that even though 
guildmasters now have Has_access, +jobs .. they do not have access to +myjobs.  
I know higher staff have access to both.

Can I give them access to both +jobs and +myjobs?

Original comment by K.Jisa...@gmail.com on 22 May 2014 at 11:10

[GoogleCodeExporter]

They should still retain +myjobs access (and in fact expand their +myjobs to 
see jobs in their newly-accessible bucket) - what is the error they are 
receiving when they try to use +myjobs? Or just a lack of data?

Original comment by Fleety...@gmail.com on 22 May 2014 at 11:18

[GoogleCodeExporter]

Well, the error was "You have no +jobs" even though I have 2 jobs that are 
tagged and assigned to the guildmaster.  But if I make the guildmaster use the 
+tps to open a job, then it show up under +myjobs.

hmm. when I try to have the guildmaster tag itself for the other two jobs, it 
says they don't have the access. Which access controls that?

Original comment by K.Jisa...@gmail.com on 22 May 2014 at 11:21

[GoogleCodeExporter]

Ah, I found how to change the owner of the job. been looking for that for weeks.

Still need guildmaster able to tag others to their jobs.

Original comment by K.Jisa...@gmail.com on 22 May 2014 at 11:28

[GoogleCodeExporter]

You probably don't want Average Joe Player to have access to the /tag command - 
it packs a powerful security punch - it is essentially giving a player the 
ability to give out keys to the job system. The player can then read every 
comment in a job even though that comment isn't published. It's essentially 
giving them high-staff access to the job, which isn't necessarily a good thing.

Can you give me your address and port so I may look at the configuration?

Original comment by Fleety...@gmail.com on 22 May 2014 at 11:29

[GoogleCodeExporter]

mordor.localecho.net 2203

page MB

Original comment by K.Jisa...@gmail.com on 22 May 2014 at 11:31

[GoogleCodeExporter]

You can set multiple owners for a job, too, in lieu of tagging.

Original comment by Fleety...@gmail.com on 22 May 2014 at 11:33

[GoogleCodeExporter]

Looking at the code for the comsys, I don't see anything in there that would 
add jobs to channels (the @aconnect is the only thing that would, and helpfiles 
claim that only applies to playertypes).

To confirm this, please try the following experiment:
- Purge all recycled dbrefs and clean up your channels to remove any on-players
- Create a new job
- Check to see if the job is on the newbie channel.  If so, we have a problem.  
Set the channel system DEBUG or TRACE and repeat the job creation to see what 
attribute is being triggered.
- If we had no problem above, try the other candidate: create a player. Nuke 
the player.  Then immediately create a job (which will likely use that player's 
dbref.)   Is the job on the channel?  Then you've likely found the culprit.

Original comment by widdis@gmail.com on 22 May 2014 at 11:49

[GoogleCodeExporter]

The objects aren't joining, the Comsys is storing a DB# of a player that gets 
recycled that never gets cleaned up, then when you look at who is on channel, 
it shows the job.

It's an AshCom issue.

Original comment by Fleety...@gmail.com on 23 May 2014 at 4:47

[GoogleCodeExporter]

As KJ's issue is fixed (we had been using %0 when %# should be passed at the 
bucket level), I'm closing this issue.

Good luck on your game, KJ, and yell at us if you need more jobs help.

Original comment by Fleety...@gmail.com on 23 May 2014 at 4:50

• Changed state: Fixed