Wedge
Public area => The Pub => Features => Topic started by: Arantor on November 5th, 2012, 03:44 AM
-
We've all commented in the past about the inanity of 'Regular Members', about the various issues with it and so on.
While working on the member groups configuration page, it just occurred to me - what if, for the sake of argument, Regular Members were to be an actual physical group?
It's not, in any real sense of the word, a physical group. You can't rename it. It doesn't show up on the left anywhere (which is, mostly, the reason for it being a phantom group). Users often want to put users into a specific group on registration - why not make it so they actually DO go into a physical group at registration rather than this phantom group?
Other than having to tweak some of the display code, not to mention some of the management logic (like preventing users deleting it, and to prevent it being changed to another kind of group), I see no reason not to do this.
On the flip side, it would allow you to do things you currently can't - you can't currently set the list of boards accessible to Regular Members as a whole group. You have to do that one board by board, even in SMF, because the edit-membergroup page only works on cases where the group id is 2 or 4+ (global moderator and any group that isn't guests, regular members, admin and board moderators)
I'd love to hear more opinions on this, especially from people who know the code base. I don't see that it should affect things that significantly anywhere.
-
I like the idea quite a bit actually. I think I was more annoyed that I could not rename it more than anything else. Making it a physical group sounds right to me.
-
*Trying best not to sound idiotic*
Member group for an actual physical group, sure why not. This shall definitely make management easier. There should be an option added to "Main configuration" in admin interface that would ask which group should be treated as main member group. Then tools available such as "create/duplicate new Regular Members group optionally including all users/some/users from group(s)...", "... But exclude users from certain group(s) or list of user(s)". Might be a performance issue somewhere, I hope not.
Or groups created/existing groups (Each group found in database) shall have a new column to signify whether or not it's "the Regular Member group". <--- Might fix performance issue & a possibility of having more than one Regular Members group(for some weird reason) that new members can be added to upon registration.
Edit: HEY!! I WANTED FIRST POST!!! -.-
-
There should be an option added to "Main configuration" in admin interface that would ask which group should be treated as main member group
I am not going to get into that particular little dance because there is a LOT more logic at stake and a lot more to go wrong if it gets messed about with. However, making the Regular Members group be that group - and NEVER ANYTHING ELSE - will solve problems.Then tools available such as "create/duplicate new Regular Members group optionally including all users/some/users from group(s)..."
"... But exclude users from certain group(s) or list of user(s)". Might be a performance issue somewhere, I hope not.
Let me explain. All users when created get stuffed into group 0, Regular Members. I'm just proposing that this group be a real group. That you be able to assign badges to it, or manage like it a regular group should you want to do so. But in all other respects it is no different to the current regular members group as it stands.Or groups created/existing groups (Each group found in database) shall have a new column to signify whether or not it's "the Regular Member group"
If you have a group that you can manipulate where users go when registered, job done. You don't need to fuck about creating new groups that mimic it. If you can give me one meaningful case where this would be advantageous, where it can't be done better some other fashion, let me know. I'm willing to listen. But I'm pretty certain that any case you suggest, I can figure out a better way of doing it than this clusterfuck of confusion.
-
I should mention it's two different ideas to solve same problem. One I thought would be more efficient than other (Depending if query has to look up main configuration or not, or use vice versa, whichever is better).
But in all other respects it is no different to the current regular members group as it stands.
Why would you do that? It's almost like the entire point of what I'm proposing got missed.
Why would you want this? I cannot think of a quicker way to confuse the hell out of users.
People would be lost/confused on boards that's so big and the website author may want four different boards, but Centralized database for ease of management and future implementations of new external/internal codes that would work with this software.
-
I should mention it's two different ideas to solve same problem. One I thought would be more efficient than other (Depending if query has to look up main configuration or not, or use vice versa, whichever is better).
Exactly. I ended up thinking of making Regular Groups "almost not special", just something that affects signing up and displays on forum index page. Since pretty much everything else already implemented. :/ I didn't mean for this to be a "Do away with Regular Member groups" idea.
Something useful for people managing a board that houses four different websites that acts like four different boards(possibly, different index page and customized sign up page). But the websites are related in some way (Centralized for external features not-in-the-forum-content such as website homepage). People would be lost/confused on boards that's so big and the website author may want four different boards, but Centralized database for ease of management and future implementations of new external/internal codes that would work with this software.
Either way, you're suggesting a big change that affects a *minute* percentage of people.
-
Why not entirely remove the idea of a special group and just make Regular member like any other group, and make the default member group admin adjustable?
-
That's essentially what I'm proposing, though you absolutely *have* to have a special group of some kind. Just like you absolutely *have* to have a zero post count group. Otherwise bad stuff starts happening (though, ironically, this would be less bad than what currently happens...)
-
Usually when I hear people saying they want users to go to a specific group at registration they mean a group the user can select at registration. For instance say the site was for cell phone users, the user could select from Android, iPhone, Windows, etc. Then each group may have group specific boards as well as the general ones and or a badge.
Technically as it stands the general members group gets tagged as "registered" then uses the post count based groups. In that sense it is functional as is. *shrug*
-
Thanks for bumping that topic, one of many I'd missed... (Would probably have found it if it had a more explicit name :P)
Oh, Noisen.com actually had from day one a specific 'regular members' group where all new members were put it. IIRC, it's nearly built into SMF itself, you just need to change a line or two in Subs-Members.php or whatever, in the registration function, there's a place to force a membergroup for new members. So, that's what I did... And it's easier to manage.
It'd be nice to move all members into a special group indeed. But how do we do that on import, eh...
-
Better question is *why*.
As the DB structure stands, we *have* to provide a group for users to go to. Group 0 absolutely has to exist in some fashion. All I'm essentially doing is converting from being a phantom group into being a real group, albeit one that you couldn't remove.
-
A real group with ID 0..? It doesn't make (too much) sense to me.
I'd rather have an extra group added by the installer (or importer), and everyone with group 0 would be put into it. It would simplify code refactoring a lot because you don't actually need to check everything again.
-
For what purpose, though? What would you do with this extra group?
Group 0 MUST by definition exist anyway. I'm just trying to avoid creating an extra group that would do exactly the same thing that you're proposing, only without making an extra group to do it.
Consider what you've just said now imagine that it happens to be number 0 instead of number 9 or 10. You still have to do all the same checking you would before.
-
I guess I'll just leave the programming to you then...... :niark:
-
It's a long way down my to-do list >_<
Finishing this damnable ban system is higher up.
-
Oh, take your time...
I have a feeling Wedge final won't be out for a while... :whistle:
(And we still haven't released Alpha 3... >_<)
-
I thought Alpha 3 was going to be before the banning stuff but I already committed some.
Part of the problem is I don't know how to make the ban interface work well and partly that I think I need to make wider changes than I originally thought.