Remember That Modern Jobs System?
-
So yeah, Remember that promise I made you? Well I'm starting on it in my freetime since I finished porting sheets over on RFK. That being said, here is the Github wiki where I'm listing out what I plan to do.
https://github.com/ccubed/MuReq/wiki
Does anyone have any comments on what's there or want something added?
-
-
"Sources" - I think that this would make more sense as "History". Actions taken on a record should be trackable and auditable. Someone gets added, removed, changes are made, movements done, attributes on the record changed, etc.
-
Better Permissions - This should be setup so that any type of Group can manage and admin a job queue. It shouldn't require bits. This entire idea should be modular and understand 'super admins' (probably Staff or Wizards), 'admins' (any group that can be defined), and 'users' (any group/specification that can dictate visibility, submissions, etc).
-
Categories - This might be better served with 'queues', each with their own management/admin team, workers and so forth. You might be able to use some sort of 'tags' idea, too, if further 'categorization' is needed, especially for searches, filtering and so on.
-
Actions - some actions may be allowed on some queues, not allowed on others. Maybe a use case arises where one queue does not allow adding people to the ticket. I could see Complaints being this way. Another use case might not allow submitters to close the ticket, only the admin group can. Rights per Action should be granular.
-
-
@Rook: A truly granular permissions system like you want would probably be hell to code without a DB but not impossible. However, given the average person who would end up using the system, I find myself wondering if anyone else would want it. Coders would, but not all games have them (in fact, it's becoming more common for games not to have coders and rely on those of us in the wild to make their code).
History is an implied feature. As for groups, Groups can be made, but see above. Making simple groups that represent groups of dbrefs though would be simple. Could probably even allow people to make search queries for them.
-
I am also working on a system like this. Well, revamping the one I already wrote. So I do have some opinions on what I want, yes. I'm not trying to derail your effort, and will contribute any ideas and code where I can!
So.
Granular permissions, to me, mean that different 'queues' or 'buckets' or whatever you want to call them can have different sets of permissions settable easily (without coding up function attributes for example), and apply those permissions to IC or OOC groups or individuals.
- Staff (I still prefer that this NOT be coded against a bit or flag, maintain a list or attribute)
- IC Groups (Sabbat, Camarilla, The 'Clickers' Cabal, Law Enforcement)
- IC 'races' (Vampires, Weres, Autobots, Unapproved Characters, etc)
- Public
- Invite-only (essentially, someone has to be added manually to the record)
These can be applied to various 'roles', and roles can have multiple entries. If you appear in any group, or are mentioned by dbref, in any 'role', you have those privs.
- Read
- Write/Edit (can edit the body/title of the original submission)
- Contribute/Comment
- Admin (can move, close, reassign)
- Inviter (can add more Readers or Contributors)
In a lot of cases, I would guess that the system would attribute the record originator to be #1, #2, #3 and #5, and that Staff would be all plus #4. In some cases, however, you might want to set up Groups to be overall Roles in a queue. So your IC/PC Prince could automatically have Roles #1, #3 and #5 in the Camarilla queue, but could not Admin the record nor Edit it. This would allow your IC PCs to answer a lot of items in the queue, especially for IC things like meeting requests, IC information requests, and so forth, and Staff don't need to be involved. (Again, this is for games structured like this.)
This allows you to open up the system so that Roles != Bits. Storytellers would not need a Wizard bit to simply admin a queue. Just build a group as you mentioned, and assign the role to the group.
I can show you what I mean on Shards, if you want to poke. I've built @Groups as an underlying system to the entire game, and everything I am coding is coded against that idea. So far, my BB system uses this approach, and the very similar queue/request system will, also.
-
I didn't lie! Any opinions?
https://github.com/ccubed/Mu2/blob/master/Jobs/MuReq
Small Explanation:
The system isn't meant to be tied to an Opened By attribute. Anyone using +request will instead be added to commenters. No more binary permission system. Readers can read a job but not comment, Commenters can read and add comments. Staff are always both on all jobs.Flags assign extra permissions. A global job makes every player a reader/commenter. Archived means that a job only shows up when searching for archived jobs but not in normal job searches, a closed job shows up in normal job searches but shows closed, a held job shows up in normal searchs as held, a staff job is only visible to staff.
Comments have per comment flags for readers and staff. If a comment is set staff only staff can see it. If a comment has readers specified only staff, the person that wrote it and those readers can see it.
Jobs are organized by categories (buckets) and tags (can be as many as you like). Jobs only ever have one category.
-
For those that want it, the first major release of jobs 2.0 is ready. I'm pushing it to our game now. This should be a working version minus any bugs. I'll be fixing those as I go along. Submit issues if you find things or want things changed.
-
@Alzie said:
For those that want it, the first major release of jobs 2.0 is ready. I'm pushing it to our game now. This should be a working version minus any bugs. I'll be fixing those as I go along. Submit issues if you find things or want things changed.
What's the likelihood that this won't vomit percent-signs on Penn?
-
@Bobotron said:
What's the likelihood that this won't vomit percent-signs on Penn?
Considering Alzie's fetishistic devotion to Penn, probably pretty good.
-
It works. It looks good. No percent sign vomit. Example of job output.
-
-
It's only getting better @bobotron. I've changed a bit around but here's some more shots of it.
+jobs output: https://gist.github.com/ccubed/b8a532fce646e84e806e
It's different, yes, but this job system isn't meant to spit a massive amount of useless information out at you. It should be easier to find the jobs you need to work, not force you to slog through 289 jobs that you're not looking for.
+job # from a staff bit: https://gist.github.com/ccubed/93586f4972105111d18b
They see everything. I changed it around and it now shows [Comment ID] or [Comment ID-Staff] to indicate flags the like.
+job # from a player: https://gist.github.com/ccubed/5fdb8579a871862af2b8
On the other hand, the player only sees two comments. But what if we wanted only our friend sasha to see comment #2. Well per comment reader blocks work. Yes they do.
+job from the player after I blocked them on that comment: https://gist.github.com/ccubed/426b8380a868c29a1584
And sample output from searching by +jobs/mine: https://gist.github.com/ccubed/a7870dea1d55b5475877
