Wedge

Well, I'd love to have such groups, where groups are based on different criteria (I've seen 'time based' and 'karma based' done as mods) Though doing it is not simple.

Mind you, the whole way post count groups is handled is very awkward and special, and has all sorts of interesting risks, namely that it is possible to get users who are true admins by misconfiguring or attempting to remove all the post count groups.

Then there's the matter of post group permissions. Or even like-count group permissions. Is that a route we'd want to go down potentially?

I don't know, I think that user-owned groups (for starters) will only get to modify a few of the settings -- basically, the first half of the settings in the membergroup edit page. They will also be able to edit their permissions, I guess, for their own user-created boards. It gets complicated, I know, but it makes sense as well to give users freedom... Otherwise there's no point in implementing blogs or anything. Because that's really what all other forums (except for Noisen but it's pretty much proto-Wedge anyway :P) do WRONG IMHO: they consider that blogs are only to be created by forum admins, or they provide blogs to their users but they're extremely limited, e.g. they can only have one blog, public viewing, etc... I haven't looked much into other forum+blog solutions, but they all seemed to be that limited.

Could you give your opinion on that post, btw..?
http://wedge.org/pub/feats/7108/badges-and-the-displaying-thereof/msg276657/#msg276657

User-owned groups is something else again on top of the other types of groups mentioned.

The post you linked, it does pretty much cover everything, I think.

"On top"? You mean, additional groups?

And my post doesn't cover what to do when the group is Additional or Primary, though... Ah ah.

We've managed to talk about several very very different things.

On the one hand, is user-created groups. A lot of that is UI fluff. I'd argue that the badges for these should never be shown (mind you I don't see that you'd ever have badges for them in the first place, eh)

On the other hand is groups based on other criteria that isn't assigned and isn't posts, e.g. likes. Or number of topics created. Or number of attachments posts. Or total time logged in. Or karma if we still had it. This is where it becomes painfully obvious that there are problems in the post count group setup, in terms of extensibility, usability and reliability. As I've alluded to, it's possible to make people admins *by accident* by screwing up the post count groups.

Which means, then, perhaps we want to rethink how post count groups are actually managed, and not make them groups in the current conventional sense. It does also suggest rethinking how such permissions are determined, too.

I didn't mix it up, for once!Badges are set up in the second half of the membergroup editor, so I was implying that custom membergroups shouldn't be able to have badges. :)
Perhaps it could be done, but I suspect through a plugin maybe. By default it really would be opening the door to abuse. e.g. I'll just create 30 groups with a badge and put myself into them :P
(Hmm, would be interesting to ensure that groups you create, you CANNOT join. Any access permissions given to it for your items are automatically given to you anyway, as you're the author...)I guess it's something that could be replaced with, I don't know, a wizard like your moderation filters... "If person reaches (X) (Posts/Topics/Likes/Attachments/Media items/etc.), use this group for them: ..."
Eh, what am I talking about... No one would use that anyway. :PThat's an interesting remark. But I'm afraid it's not going to be a successful change. User groups are more 'interesting' for admins generally than other X-based groups because they imply seniority. If someone has 3 posts on my forum, I'm less likely to give them access to my private parts blog or something. (Not that I have such a blog, ah ah.) While if someone has 150 likes on different posts, they'll usually be well known in the forum and thus will probably be assigned some custom group anyway.

Perhaps what could be done, though, is to instigate a "minimum post count" setting that would be quite global to the forum. Anywhere you can set up a membergroup, you could also set up a minimum post count check that is done after the membergroup check. That setting could be kept either in a new field in most tables, or simply in a new table with a content_type field or something.

But, quite honestly, I think that id_post_group is... relatively well known now, and perhaps it would put off admins if we removed the system entirely. Like, it might give some users access to areas they previously didn't know about...

Yes that all sounds great, exactly what I'm after and there's lots of flexibility there for everyone.Haha yes 'Never' for the confused - although perhaps people could set it all up, with the correct image address, before switching it on later?

"How about Like based groups?" It would be cool to have a group for members who joined over x years ago, have at least y posts, and more than z time online as these would be old members who have stuck around and contributed.
But as Arantor hints it would be a bastard to set up and the support would be a never ending stream of user / set-up errors.

Thanks :)

There already are a lot of issues with users screwing it up, which means I'm inclined to simplify it, so that instead of the current approach, we actually don't have physical groups for post counts etc.

Instead, we have it such that rules are created:
* if user has 0-9 posts, show this badge/title
* if user has 10-100 posts, show this badge/title

Then we can start applying something similar to permissions - but tying it to the permission rather than the group. So for permissions, for example, permission to do X can be 'user in these groups, or has post count of at least X', similar to the power of the moderation filters system.

The only trick is doing it efficiently.

But it wouldn't be hard to stack post count badges with other badges with this set up.

I think I see. Reminds me of a quote (something like) "I spent a week on a ship with Albert Einstein who every day tried to explain his relativity theory, and at the end of the week I was convinced he understood it"

This is essentially it. I can tell you exactly how every part of the groups system works under the hood. And you'd be convinced I understood it. (You would be right, heh) But I doubt I could explain it sufficiently well to explain it to other people.

For example, as I mentioned, it's possible to screw up the post count groups such that a user could actually become an admin. I can tell you not only what circumstances cause this, I can tell you why those circumstances cause it. But if I were to do so, you'd look at me like I was some kind of loon.

But I do have to wonder whether that level of complexity is really necessary.

Well, loading additional data in loadMemberData is not a big deal (it's only one extra field at this point). The cache of fields/positions etc can be pulled from the membergroups table in probably a single query.

I'd argue that for the purposes of displaying multiple groups, you don't actually have to care about primary/secondary, but rely totally on the order specified in the membergroups themselves, for badges that shouldn't be displayed, store their position as 0, for all others store their position as 1+ to indicate the position, then just query the table WHERE position > 0 ORDER BY position, and you get that information pre-sorted too.

It wouldn't necessarily *require* a cache but I'd cache it.

That would make impossible to have badge display depend on other badges being shown or not....?
eg only show a post group badge if no primary group is set
or only show a post group badge if no other group is set
etc...

also, lmc() doesn't do the actual requests so it'd require doing an extra request, i think...