4-Sep
Today we put into play a new potential addition to take some of the hell of having administrators add and remove people from groups. As Everything2 grows larger and the proliferation of the message system spawns more community usergroups, it grows increasingly obvious that we need less administrative intervention in their management. Previously in ecore, usergroups were meant mainly for permissions management, and the message system was an afterthought. Needing an administrator to add you to certain permission driven groups (Content Editors, edev, gods, etc) made sense, and still does.

Now with the many social usergroups showing up in the system, it is more necessary that the E2 community manage their own groups. While admins will want to participate in BAP, nynvb, outies, e2comix, nocal, etc, it may be more convenient for the community organizers to add and drop from usergroups.

Meet the permissions problem. I'd be happy to reown usergroups to people, so that they can actually own them and use the standard editing to add/drop from them, but the main problem is that the doctext in a usergroup executes like a superdoc, so owning a usergroup would be infinite power on the system. We need a few documents that give you accessors around this problem:

In steps:

- simple usergroup editor, an easy way to add and drop from groups in one step. This is actually currently a better interface than what the admins have, so we'll be adding that into the standard administrator toolkit shortly. If you have any groups that you administer, then it will give you the chance to add/drop from them. gods,content editors, and edev are not ownable. To set the usergroup ownership, administrators will need to edit:

- usergroup owners for now until we can figure out a better membership plan. Only one owner per group. The first value is the node_id of the usergroup, the second is the node_id of the owner. Let's say in this limited example that I own BAP.

(BAP), number 1103744 would have a value of (JayBonci) 459692. This is an example in the site right now and will be changed to whoever wants that group on it's final approval.

This is an RFC from the administration and may not be approved. It is merely a proof of concept. Thanks.

16-Sep
Locked out guest user from the weblog part of the Epicenter. That still needs to be cleaned up badly, and I'm not exactly sure the best way to do it.

Applied a patch by fuzzie/in10se for a bug in User Search XML Ticker II. Whoops =) My thanks to them.

23-Sep
Fixed time problems on server. We shouldn't need to do icky hack stuff in timesince anymore, but you never know. It seems to be good on spectre and hillgiant. Also dreamed up a new full text search algorithm, a really really sweet one, but it doesn't really apply to e2 sadly. HOWEVER! The caching scheme part of it does, so I'll either write that up for technical comments, or just do it. Honor roll should be in play soon as well. I'm making headway on the right way to do it, but I'm hung up on the best method for detecting how you go up a level.

Fixed speed problems associated with the newsify functions. Basically they were grotesque. Everyone has lost their weblogging abilities (Newsify, Clientify, Sciencify, etc) until they visit their homenode, where it will be seemlessly regenerated. Previously, we were cycling through every weblog group every page load for every user. Now, we simply create the links if we need to, saving valuable time and cycles. This changes a few functions:

Created the debuggers usergroup. Basically it allows normal users to get html output on errors as if they were in gods. This is to help the few qualified edevers spot errors when they won't repro for me.

Added the code in from the groupCache work from the latest ecore-pre1.0 CVS tree. This caches group membership in such a way that is always worst case on the first look up, and then O(1) on secondary lookups. This is all cached to $DB->{cache}->{groupCache}, and is heavily modified from the CVS tree, but it's the same basic idea. It also makes isApproved and isGod the same efficiency as exists($HTMLVARS{group_gods}{$$USER{user_id}}); groupCache stuff test correctly, and feels faster at peak cache performance. Worst case, it's no worse than what we currently have. I've got Dr. Dannye, the lag detector, working to see if he thinks it's any faster.

I think I fixed the EDR as well (because I'm on fire today). I added a one-line change to the emailReport.pl script that allows it to send more emails. I think we're overloading exim on scalebone, so I added a sleep(5); to the script. It takes longer to send, but all of them seemed to have gone out, which is good. I'm going to sick edev on it for a few days to keep an eye out for all of them.