Wedge

Yeah, don't worry too much about the code stuff, that was more a passing comment for anyone who is interested in extending that menu in a specific way ;)

I did start, briefly, on making it able to show two edits side by side and show the changes, but I got sidetracked with personal stuff and haven't gotten that far with it. (Sadly, MediaWiki has a rather nice piece of code derived from GNU diff, but it's GPL and thus not suitable licence-wise)

There is an override in loadMemberData that if you're an admin, the badge won't be overridden by the moderator badge.They do get all the related permissions automatically, but on top of that a plugin or whatever can expressly check for being a moderator with that in_array check, should they want to do so (as opposed to checking allowedTo(moderate_board))But it does give them the admin panel - just the bits they have access for. Give a group access to edit news, and the only thing they see in action=admin is the news option. The mod centre was designed to work the same way in theory but practice doesn't agree.Actually, in a base install it is - subject to the feature being enabled.Well, 1.1.x's code and 2.x's code are rather different (and the installer makes a royal mess of it, too, creating a new profile for each and every board that has local permissions) but the concept is workable.UI definitely. Internally... very probably, because of hoops you end up jumping through to perform the tests and still keep it fast.Hell yes. The biggest complaint I've had is taking into account approve-posts permission - and there it is, right there, pre-cached and 'dealt with' already.Permissions, yes, optimisation, maybe. There are people who know MySQL better than I do in the SMF fold (Vekseid, Mark Rose to name two)

Also, I thought you were still working on it at present?I think renaming it would help, but I think overhauling the UI will help even more in the long run - but the rename is good for now.The implication is that a surprising amount of places simply do not use the underlying functions to confirm access at all. I discovered this last night - Display for example does not itself do {query_see_board} in the topic to validate access to the topic, it relies on loadBoard having already done it. Point is... make *sure* loadBoard is working correctly as far as access to boards goes, and to topics if a topic is specified, and that has a lot of knock-on effects, not just for display, but anywhere ?topic is in the URL (e.g. attachments, remove topic, just to name two)See, the notion of having a single group or contact list never actually occurred to me, I assumed right off the bat that multiple lists was the aim.I'm not nearly familiar enough with what UP offers, perhaps I should learn! But yes, it's looking like a sub-select or a join, which can get creaky if not done carefully. I foresee lots of experimentation on this one.Right now, it's 'relatively' cheap. It's still fixed-length rows, but the minute a text field is added to it to contend with the whole aspect of multiple groups attached to it, it's going to get expensive (and the alternatives, like SET columns, aren't really good alternatives). Also note that MySQL is still not too hot about optimising OR branches; it can optimise AND branches cleanly enough but it still ends up doing a lot of work for OR cases.I understand the nature of their complaint on it - being a binary state field, you can't actually optimise it that heavily in an index. An index works best if it's selective, or at least sufficiently distributed such that picking a value excludes a sizeable percentage of the rest of the table. approved being a two-state field is never going to exclude vast amounts of the tableset so you never get any advantage out of indexing it.

We'd actually get more benefit from keeping an accurate track of moderated posts in a topic and topics with moderated posts in a board - so if there's nothing that has pending moderation status in that board or topic, don't perform that test.Because you don't have to expressly store it in the table then. For example, if you handle 'view replies' as a permission, you can simply exclude massive portions of the table, very cheaply.The test is really (privacy = contact AND privacy-list IN (user contact lists)), isn't it? Since the user's contact list will be part of the user's own data and thus available for query insertion?

Oh yes. :DThat's a very big issue, yes. That's why for example r1373 (and 1374) was necessary.To a point the mod cache is not significantly useful but important - because it exemplifies the point I've been going nuts over: board permissions that apply outside of a board context in some fashion, that have a bearing on access even outside of their board.

For the most part, you only need to be bothered with standard permissions checks (allowedTo style) because it's surprisingly infrequently that you worry about board permissions outside of a board context. Even in SimpleDesk where I had the same situation to encounter, even there it actually was not a problem in the same fashion (and there was no such thing as general vs 'board' permissions, everything was implied to be a board permission of sorts)

But in SD's case, I didn't have separate logical structures to contain things - when you loaded permissions, you did so in a single hit, and loaded access to every board's permissions in a single hit, meaning you always knew which departments you had what permissions for.This is a special case by definition because you can be a moderator on a board without being a board moderator (and without being a global moderator) It is this level of complexity that actually makes SMF so difficult to configure, even if conceptually/codewise using the permissions system is made so easy.can_mod, supposedly, is 'I can moderate somewhere' while is_mod is 'I can moderate *here*'. Primarily IIRC can_mod was supposed to be used to control access to the moderation centre but this changed in RC4 when fixing a related bug.Firstly, there have actually not been that many overhauls - there's 1.x and there's 2.x permissions from what I remember of 1.0 vs 1.1. There are three permissions related changes in 2.x vs 1.x that are of relevance to us:

* profiles
* post approval
* the mod_cache

(The whole simple vs classic thing is purely cosmetic. It's also stupid, but that's a debate for another day.)

The whole profiles thing is interesting. I actually remember an argument I had with Antechinus about that[1] over reverting to 1.1.x local board permissions vs global ones, but honestly that's about as confusing! The reason for the argument was because of an important lack of understanding - there was a *reason* profiles were adopted instead of local/global board permissions, and that was to simplify applying the same permissions to multiple boards at once.[2] It did, incidentally, fix a few bugs in 1.1.x's 'profiles' as they stood, too.

Fortunately for the most part, the profiles mechanism doesn't really make that much difference for us in terms of mechanics, because whatever we do, it will probably use some of the same infrastructure.


Then there's post approval. The whole permission implementation of that had some convenience-for-UI-building factors (and still does, in ways I have not yet solved for moderation filters) but it causes the problem we've been bouncing around here - that you need to have some conceptualisation of board-level permissions being applied to a context outside of boards.

Prior to post approval's introduction, there was never a context in SMF where you'd ever need to understand board level permissions properly in places that have a meta board context - yes, search/unread/unreadreplies/recent had *some* idea of board level permissions, for whether you could reply to a post or edit it or whatever, but all that was doable after the event, as it were - you only had to worry about board *access* to see posts, not a permission attached to whether you could see an individual post.


This brings us to the mod cache - whose sole existence, if I'm any judge, is to mitigate the very performance issues that I'm getting at. Now, here's the thing: the reason it's not used that much in SMF is simply because there are that few places where having board-level permissions outside of a board just doesn't make much difference. Primarily it supports post approval - but the rest are nice convenience features, and that allowedTo() is probably more important.


So, where does that leave us? It leaves us with a permissions system that I've wanted to overhaul for a while - because SMF's permissions system is unintuitive. It's very, very powerful but the price paid is the complexity of actually trying to use it - and almost everyone I know (including me) has misused it and used it incorrectly to do things that shouldn't be done that way.

For example, if you have two or three 'teams' that are all, practically speaking, global moderators but have different badges, the correct thing to do is make new groups for each team that all inherit from a parent group so you manage the permissions centrally - but most don't.

The really sad part is, I don't have an answer yet. I've had bits of answers floating around and my gut instinct is to dump SMF's permissions core and merge in SimpleDesk's in some respects but that's not really where I want to go with this.

What is clear is that SMF's permissions are broken, and a lot of that is down to perception: as I identified when figuring out SD's permissions, a lot of the problems in SMF are really caused by people conflating groups and roles, and building on that incorrect premise. It's almost like we need to separate groups from permissions properly.

1.	It was in that conversation I realised how doomed SMF really was.
2.	The point of the argument is that to fix a problem you must understand how the problem came about. Going backwards doesn't mean you go forwards if you don't understand what you're undoing in the process.

I will look into it, need to go out for a bit first.

Yup, just like my screenshot shows ;)

(1 file, 1KB)

Revision: 1374
Author: arantor
Date: 22 February 2012 01:19:01
Message:
! Forgot to remove some debugging code from Load.php (Load.php)
----
Modified : /trunk/Sources/Load.php

The history of a post is pretty post centric?

Been thinking about this one for a while, and finally started working on it today. So far I've got it able to store the edits as they're made (which is by far the easiest bit of the code) and added an item to the menu to view the edits.

It's also, interestingly, exposing a weakness in the post display, in that there's no way to alter the items (other than those in the menu) by way of a hook - nor is it possible to do what Niko's mod did and have the 'last edited' text be a suitable link. Not yet sure how I want to deal with that.

As far as the menu goes, the real struggle - such as it was a 'struggle', depending on your definition - was making the text be different between menu instances, to include the number.[1]

But here's what I have so far. It's not very exciting, because I haven't gotten onto the real meat of the display yet, but that's OK, I haven't spent that long on it yet.

1.

Nao wrote that code and it is very, very efficient, but doing something like this is atypical - and as a result, a little bit tricky, but nothing that can't be solved relatively easily, all that happens is we create placeholders for each of the counts and use those, e.g. if a post has 1 edit and another has 2 edits, we create dynamic $txt entries to cope with it so they each get a 'unique' identifier. If you're not planning on touching that menu it really doesn't matter to you, other than the fact it works.