Issue 173 in anomalyjobs: Help with buckets and access

[anoma...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect

New issue 173 by K.Jisa...@gmail.com: Help with buckets and access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

--
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

[anoma...@googlecode.com]

Updates:
Owner: Fleety...@gmail.com
Labels: -Type-Defect Type-Task

Comment #1 on issue 173 by Fleety...@gmail.com: Help with buckets and access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Updates:
Status: Completed

Comment #2 on issue 173 by Fleety...@gmail.com: Help with buckets and access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #3 on issue 173 by K.Jisa...@gmail.com: Help with buckets and access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #4 on issue 173 by wid...@gmail.com: Help with buckets and access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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 (wid...@gmail.com) and I can join
you on your game to help you implement this.

[anoma...@googlecode.com]

Comment #5 on issue 173 by wid...@gmail.com: Help with buckets and access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #6 on issue 173 by K.Jisa...@gmail.com: Help with buckets and access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #7 on issue 173 by Fleety...@gmail.com: Help with buckets and access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #8 on issue 173 by K.Jisa...@gmail.com: Help with buckets and access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #9 on issue 173 by Fleety...@gmail.com: Help with buckets and access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #10 on issue 173 by Fleety...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #11 on issue 173 by K.Jisa...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #12 on issue 173 by Fleety...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #13 on issue 173 by Fleety...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

Oh yeah, are your job objects still joining channels?

If not, how'd you fix it?

[anoma...@googlecode.com]

Comment #14 on issue 173 by K.Jisa...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #15 on issue 173 by Fleety...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #16 on issue 173 by K.Jisa...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #17 on issue 173 by wid...@gmail.com: Help with buckets and access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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?

[anoma...@googlecode.com]

Comment #18 on issue 173 by K.Jisa...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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

[anoma...@googlecode.com]

Comment #19 on issue 173 by Fleety...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #20 on issue 173 by Fleety...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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

[anoma...@googlecode.com]

Comment #21 on issue 173 by Fleety...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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

[anoma...@googlecode.com]

Comment #22 on issue 173 by K.Jisa...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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?

[anoma...@googlecode.com]

Comment #23 on issue 173 by Fleety...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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?

[anoma...@googlecode.com]

Comment #24 on issue 173 by K.Jisa...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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?

[anoma...@googlecode.com]

Comment #25 on issue 173 by K.Jisa...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #26 on issue 173 by Fleety...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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?

[anoma...@googlecode.com]

Comment #27 on issue 173 by K.Jisa...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

mordor.localecho.net 2203

page MB

[anoma...@googlecode.com]

Comment #28 on issue 173 by Fleety...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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

[anoma...@googlecode.com]

Comment #29 on issue 173 by wid...@gmail.com: Help with buckets and access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Comment #30 on issue 173 by Fleety...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.

[anoma...@googlecode.com]

Updates:
Status: Fixed

Comment #31 on issue 173 by Fleety...@gmail.com: Help with buckets and
access
http://code.google.com/p/anomalyjobs/issues/detail?id=173

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.