depwl9992 / anomalyjobs

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

Assigning groups to jobs #133

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create a Job
2. Create a group
3. Assign the job to the group

What is the expected output?
It should assign it to the group alerting if a member of the group doesn't have 
access to the bucket.

What do you see instead?
Instead it appears to pull all the players in the game and then says that they 
don't have access to that bucket when it should only limit it to the members of 
the group.

What version of the product are you using? On what MU* Server?
pennmush 184p1

Please provide any additional information below.
It appears that the problem might lay in the FN_JGROUPMEMBERS. It calls up all 
the players in the database rather then just the members on the group list. I 
don't know if this intentional as i haven't looked at all the code to figure 
out what it all does. Seems to me that it should only return MEMBERLIST of the 
group and check them to make sure they have access. I'm going to try to mess 
with it and see if I can get it to work. I'll post when/if I fix it.

Original issue reported on code.google.com by blank.forrest on 15 Nov 2010 at 6:08

GoogleCodeExporter commented 9 years ago
Changed FN_JGROUPMEMBERS:
&fn_jgroupmembers 
#189=switch(first(version()),PennMUSH,[u(%0/MEMBERLIST)],RhostMUSH,searchng(epla
yer=u(%0/ISMEMBER,##)),search(eplayer=u(%0/ISMEMBER,##)))

Tested that it works for pennmush.

Original comment by blank.forrest on 15 Nov 2010 at 6:15

GoogleCodeExporter commented 9 years ago
Shouldn't these functions match?  Like:

&fn_jgroupmembers 
#189=switch(first(version()),PennMUSH,search(all,eplayer,u(%0/ISMEMBER,##)),Rhos
tMUSH,searchng(eplayer=u(%0/ISMEMBER,##)),search(eplayer=u(%0/ISMEMBER,##)))

or

&fn_jgroupmembers #189=u(%0/MEMBERLIST)

Using a ufun() for Penn and not the others seems to be setting us up for a 
behavioural difference somewhere later down the line.

Original comment by kkragenb...@gmail.com on 15 Nov 2010 at 7:38

GoogleCodeExporter commented 9 years ago
I changed only PennMUSH because that is what I used. I don't know how other 
code bases work, so I didn't modify their functions. They may work as desired 
as they are. 

Yes, you are are correct in using ufun(), for PennMUSH would be correct, as I 
see it.

Original comment by blank.forrest on 15 Nov 2010 at 3:52

GoogleCodeExporter commented 9 years ago
I'm not sure I understand what the issue here is.  For reference, this feature 
was requested in Issue 22.  From that discussion, you can see there are two 
types of groups:
- static groups (membership is explicitly defined using MEMBERLIST)
- groups referenced by another function (e.g., ISSTAFF or other functions which 
reference other code, check flags, etc.)

The design is such that FN_JGROUPMEMBERS does not directly access memberlist.  
Instead, it checks the ISMEMBER function on the jgroup object.

When a jgroup is created, it is given an ISMEMBER attribute which defaults as 
such: ISMEMBER: t(member(v(MEMBERLIST),%0))

The helpfiles (+jhelp jgroups) clearly document this:  "The ISMEMBER attribute 
is used to determine membership in the group and defaults to checking the 
MEMBERLIST attribute. The ISMEMBER attribute may be changed to reference other 
tests of group membership."

So for example, you could define a +wizards group, change its ISMEMBER 
attribute to be "hasflag(%0,WIZARD)", and then the jgroup would apply to all 
wizards.

I tested the sequence in the OP in both PennMUSH and MUX and it appears to work 
as designed.  The only problem would be if OP changed the ISMEMBER attribute on 
the group to something other than the default, which includes more players than 
was intended.

Original comment by widdis@gmail.com on 15 Nov 2010 at 7:08

GoogleCodeExporter commented 9 years ago
Okay, here is where everything went wrong. I did not look at the code very well 
to totally understand what was happening, or failed to read and understand the 
help files. So what happened was that I overwrote the default ISMEMBER because 
the message displayed to me from the code and the documentation both together 
lead me to believe that I was suppose to put a function into ISMEMBER, or use 
MEMBERLIST to have it use the memberlist. I didn't know that it automagically 
put in its own function. I has since reverted the code back to the initial 
settings and everything works fine.

Please close this bug as it isn't a bug, but USER ERROR.

Original comment by blank.forrest on 15 Nov 2010 at 10:38

GoogleCodeExporter commented 9 years ago
User error is usually the fault of documentation.  I see that the emit you get 
after creating a jgroup is confusing.  I'll clarify it.

Original comment by widdis@gmail.com on 15 Nov 2010 at 10:44

GoogleCodeExporter commented 9 years ago
Issue 132 has been merged into this issue.

Original comment by widdis@gmail.com on 15 Nov 2010 at 10:45

GoogleCodeExporter commented 9 years ago
Emit clarified in r367.

Original comment by widdis@gmail.com on 10 Dec 2010 at 11:40