Custodial Rights

Hey all, hope you’ve been well. I’ve been busy in the past few weeks and, as of the time of posting this, have already rolled out a good deal of what I’ve been working on.

In my previous post I offered some broad strokes about what I was doing and this time around I want to talk about the behind-the-scenes kinds of things that I had to do to overhaul the moderation/staff system. This was the classic “not too difficult to implement once you have a thorough plan” kind of deals—the real issue was devising a plan in the first place.

My objective was to have a flexible system which could have different permission level checks depending on the particular account’s rights. The old Kusaba X way of doing it was basically having checks for being an Admin, Mod or Janitor that were different bits of code. There were not always implemented in a consistent manner in the places where there would be checks. I had already simplified some of it some years ago but it was still a somewhat inelegant system.

So the first two things that needed to happen was to a) standardize how privileges were tracked in the database for both existing types (Admin, mod) and any future types and b) create a generic bit of code that could be a drop-in replacement for the various existing calls. The former was easily done but required a partial rewrite of the bits that add staff or change permissions to prevent any potential exploits. The latter leveraged the new standard levels to create a straightforward check where instead of inputting a user name or checking specifically for a role, it checks the minimum amount of privilege needed to interact with the system. It’s flexible and at least as restrictive as the old system. There’s way more complex solutions possible that are potentially more “secure” but I settled for something that was at least as secure as the current system because it’s good enough for our needs.

The testing phase, as you might imagine, lasted for a while since I more or less checked every authorization call in various places and made sure that it all worked with the new system without problems. As the software is a mix of PHP and static content, there’s a number of calls that are made, for example, when posting that might necessitate checking whether a user is privileged. This is separate than the manage page but uses much of the same backend.

While it’ll become clearer why these changes were needed in the first place and not just necessary for strictly moderation purposes, I’d like to first talk about the revived janitor system. As any good imageboard software, there was a third tier of moderation below admins and mods in Kusaba X. Janitors could only delete posts and had per-board permissions. They could not see any moderation tools, really. We never really had a use for them as a result. Per-board moderation was all but removed from the code by me some time ago for everyone and, with these changes in mind, I had thought of bringing back lower-privileged helpers.

The site still gets an amount of spam and crap despite its many filters and bans. And I don’t really feel comfortable with adding more moderators with broad powers because there’s not that many people I trust to be both good enforcers with a light touch as well as be active enough to catch sudden developments. Historically we’ve had a very poor showing by the members of the community that were brought on board with one or two exceptions.

Hence, “janitors” that can’t really see IPs nor place bans but can delete content. And not just any content—but exclusively new content or content that has been reported. And even then their actions can be reviewed by my at a later time and bans handed or even restored depending on whether or not I think the call was justified. The idea is to open up the job to a number of people and minimize the risks of rogue malicious activity.

All of this needed quite a few reworks and new bits of code to put into place. For example, making so the reports page in the moderation area was clearer and usable by the new class of users. Posts may appear to be deleted but they are sent to a temporary area and added to their own table in the database so that the actions can be later reviewed if necessary. Conceptually easy, it required many lines of code and a lot of idiot-proofing and redundancy to make sure that the system doesn’t have bugs or glaring errors. Things like adding buttons when logged in on the board pages for quick deletion as well as making sure the checks were done in a sane manner took time and testing a plenty.

I also took the time to enhance related systems such as the ability to view deleted threads, adding the ability to see these “quarantined” images along with posts so that I can make sure that it really was in violation of the rules. I found that, as is usual with Kusaba X, altering a small part of code makes it necessary to look at other parts and before I knew it I had extended one of the primary was posts are processed with two new methods to its class and added several new tools on the moderation-side of things. A benefactor to all of this was the logging system that now keeps track of more of the actions taken by staff.

I’m certain that there’s a fair bit I could rewrite to consolidate code after I’ve been mucking about with these systems. But, if I had done more than I had, I would have been at this for several weeks longer. I tried not to lose sight of the main objectives and it’s been an interesting experience that’s let me appreciate how to better manage account privileges and checks.

Normally I’m a little coy with what I’m going to do next but a big reason for this overhaul was to lay in the groundwork for expanded tagging for the storylist. It is now trivial to create a new class of privileged user that has the rights to edit tags or synopses. And I very much plan to do so. There are many other things that need to be done to have an easy-to-understand system in place but this was a required stepping stone.

The alternative would have been to make a user system from scratch that would be most likely separate from the rest of the site’s functions and that would take far longer. Still, there’s a lot more that needs to be done; mainly having an easy-to-use interface that allows for changes to be made with minimal effort but that also tracks who did what and allows for reversion when necessary. All of this and more, including a way for management to get notifications sent, are what I’ll be working on come the next few weeks. If all goes well, it should come together somewhat quickly. The lack of time and resources has slowed me down a little this last month (as well as some developments in my personal life) but I’ll keep at it as always.

Before ending this with my usual goodbye, I’d like to state that I’m extending an offer to all patrons to contact me if they’re interested in helping keep the site clean of spam and the rare rule infraction. Contact me either directly through Patreon’s messaging system or through Discord and I’ll set up an account for you. In all likelihood this class of staff will also get full tagging privileges but I’ll also open up recruitment for storylist-only type accounts when they’re ready and to a wider group of people.

Until next time, take it easy!