Page 1 of 2

group_id field in users table

Posted: Sat Jun 27, 2020 2:57 am
by BarneyC
Is the group_id in the users table a remnant field or is it still used? Intuitively I'd think this is the default group, but it doesn't seem to change. For example:

User Foo => group_id = 7 (newly registered)

I remove Foo from newly registered => group_id is still 7
I add Foo to registered Users (group_id 2) => Foo's group_id is still 7

I get how user_group works, but I don't see how the default group is determined if group_id isn't the default group.

I want to move customers who buy something to registered users programmatically when they buy something, but I'm not entirely sure how the default group is determined.

Re: group_id field in users table

Posted: Sat Jun 27, 2020 3:48 am
by kinerity
Did you make it their default group?
acp_groups.png
acp_groups.png (5.02 KiB) Viewed 658 times

Re: group_id field in users table

Posted: Sat Jun 27, 2020 7:25 am
by david63
BarneyC wrote:
Sat Jun 27, 2020 2:57 am
I add Foo to registered Users
Why are you adding any user to the Registered Users group? All users should be in that group at all times

Re: group_id field in users table

Posted: Sat Jun 27, 2020 4:22 pm
by BarneyC
kinerity wrote:
Sat Jun 27, 2020 3:48 am
Did you make it their default group?

acp_groups.png
I can't even find what you're pointing at. What screen is this on?

Is there a screen where I can see a user and all the groups they're in? There isn't even a "default group" in the Edit user screen

Re: group_id field in users table

Posted: Sat Jun 27, 2020 5:05 pm
by AmigoJack
BarneyC wrote:
Sat Jun 27, 2020 4:22 pm
the Edit user screen
From there other "screens" are available thru a combobox labeled "Quick tools". This is also mentioned and explained in the manual.

Re: group_id field in users table

Posted: Sat Jun 27, 2020 6:02 pm
by stevemaury
group_id in the users table determines a user's default group, which in turn determines their group color and rank, if any. If you did not check the box to make Newly registered users the default group for its members, their default group will be Registered users.

Re: group_id field in users table

Posted: Sat Jun 27, 2020 8:14 pm
by BarneyC
AmigoJack wrote:
Sat Jun 27, 2020 5:05 pm
BarneyC wrote:
Sat Jun 27, 2020 4:22 pm
the Edit user screen
From there other "screens" are available thru a combobox labeled "Quick tools". This is also mentioned and explained in the manual.
Yes I found the dropdowns with the alternate "forms"; it's been awhile since I've navigated this admin gui :?

Re: group_id field in users table

Posted: Sat Jun 27, 2020 8:46 pm
by BarneyC
david63 wrote:
Sat Jun 27, 2020 7:25 am
BarneyC wrote:
Sat Jun 27, 2020 2:57 am
I add Foo to registered Users
Why are you adding any user to the Registered Users group? All users should be in that group at all times
Ok, so if a user is in newly registered group he also has to be in the registered group, even though you never want him to have the permissions associated with registered users? That seems counterintuitive.

1) Why is there an option to remove users from registered users; what would be the point of doing that?

2) If you have a user Foo and he's only in group registered users, and you remove him from registered users (don't ask why), his group_id is still (2 = registered users) in the users table, even though he isn't actually in any groups. There's no warning or way to find users who are in no groups (by mistake or other reason); it doesnt complain that it can't change the group id in users because there is no other group to put there, or warn you that removing a user from registered uses is taboo. I think it *should* at least change the group id to 0, which would also make it easy to find users who are in no groups (and therefore are zombies that can't see any forums or do anything).

The *reason* for this is that I'm integrating phpBB with a website and I have to do things programmatically (and not with the buttons in the ACP).

- When a user is created on the main site, a phpBB user is created with the same user_id
- Users need to be added to groups based on their status; for example if they buy something they need to be put into the appropriate support group.

this allows us to easily allow access to the board without having anyone log-in again; in fact we've eliminated the phpBB login altogether. Syncing the user_ids allows users to have a different screen name on the board, since many users on the main site log in with their email address.

I *could* argue that add_user() *should* add the user to registered users if that's in fact required; if you add a user with group_id set to something else, it only adds them to that group. Since a user in newly registered group can never use his membership in registered users, I'm not sure why it's required, except maybe to make it so you don't have to add him to registered users once he reaches the newly registered quotas.

Re: group_id field in users table

Posted: Sat Jun 27, 2020 9:00 pm
by BarneyC
stevemaury wrote:
Sat Jun 27, 2020 6:02 pm
group_id in the users table determines a user's default group, which in turn determines their group color and rank, if any. If you did not check the box to make Newly registered users the default group for its members, their default group will be Registered users.
My question arose because group_id doesn't get cleared if a user is in no groups, and if it's set to a group the user isn't a member of it seems to be ignored. This can happen if you're coding things manually and do it wrong :|

Re: group_id field in users table

Posted: Sat Jun 27, 2020 9:32 pm
by AmigoJack
BarneyC wrote:
Sat Jun 27, 2020 8:46 pm
he also has to be in the registered group, even though you never want him to have the permissions associated with registered users? That seems counterintuitive.
Unless you grasp the permission concept of "No, Yes, Never": all members should be in the group "registered users", because phpBB needs a lowest common denominator. The "newly registered" (or any other group" adds up denials of permissions.
BarneyC wrote:
Sat Jun 27, 2020 8:46 pm
1)
2)
  1. The rare condition of turning an account into one for a bot.
  2. It's fairly easy to find out who is in no group (SQL knowledge applies). Again: the default group is primarily meant for giving the username a color; setting it to 0 would have more disadvantages than advantages (for phpBB, of course, unbound to your concepts of how operate on it). Nothing "wrong" here.
BarneyC wrote:
Sat Jun 27, 2020 8:46 pm
When a user is created on the main site, a phpBB user is created with the same user_id
That will sooner or later collide with an already existing ID; better first create a user in phpBB and then associate that ID to your "main site" user.
BarneyC wrote:
Sat Jun 27, 2020 8:46 pm
Users need to be added to groups
There's a function just for that - can't be easier.

Re: group_id field in users table

Posted: Sat Jun 27, 2020 11:28 pm
by BarneyC
2. It's fairly easy to find out who is in no group (SQL knowledge applies). Again: the default group is primarily meant for giving the username a color; setting it to 0 would have more disadvantages than advantages (for phpBB, of course, unbound to your concepts of how operate on it). Nothing "wrong" here.
"Easier" in terms of looking at a table with a DB tool like adminer. Also what is "not wrong" about a user having a default group that he doesn't actually belong to?
When a user is created on the main site, a phpBB user is created with the same user_id
That will sooner or later collide with an already existing ID; better first create a user in phpBB and then associate that ID to your "main site" user.
No it won't. There are no phpBB-only users; there's no registration. There's no phpBB login. The phpbb user table is a one-to-one relationship with the main system table. As a safeguard the auto-increment is set to a very high number on the phpbb user table so there won't be any collisions even if users are erroneously created by phpBB.

Before doing this I saw a lot of advice to use the phpBB login system for site-wide logins, but I think that's the wrong approach for multiple reasons. The biggest is that you don't have to deal with the phpBB-aware spam bots.

Re: group_id field in users table

Posted: Sun Jun 28, 2020 7:15 am
by Mick
BarneyC wrote:
Sat Jun 27, 2020 8:46 pm
Ok, so if a user is in newly registered group he also has to be in the registered group, even though you never want him to have the permissions associated with registered users? That seems counterintuitive
Not really, registered users have their permission set to allow them to perform what regular users do. Users in the Newly Registered User group (if enabled) have similar permissions but those permissions have ‘NEVER’ attributes for such things as posting (as in being on the mod queue) and PMing etc. All that happens once the user reaches the post threshold you set he drops out of the NRU, loses all the NEVERs and becomes a full member.

Re: group_id field in users table

Posted: Sun Jun 28, 2020 12:12 pm
by AmigoJack
BarneyC wrote:
Sat Jun 27, 2020 11:28 pm
what is "not wrong" about a user having a default group that he doesn't actually belong to?
The outcome is within phpBB's definition: conditions are expected. Maybe you understand it this way: there's no need for that column in the table at all and group priorities could be stored with the related groups, but performance-wise it's much cheaper to keep that one data right with the user. It still doesn't make it necessary to synchronize it also with the case of "no groups".
BarneyC wrote:
Sat Jun 27, 2020 11:28 pm
There are no phpBB-only users
Then your installation has no bot accounts, so the "who is online" part will neither show you whenever a crawler visits the board, nor will permissions for those kick in. By default account #1 is the guest, #2 the initial administrator/founder and #3 to #52 the bots.
BarneyC wrote:
Sat Jun 27, 2020 11:28 pm
Before doing this I saw a lot of advice to use the phpBB login system for site-wide logins, but I think that's the wrong approach for multiple reasons. The biggest is that you don't have to deal with the phpBB-aware spam bots.
The device was always aimed at people who wanted literally to integrate phpBB into their website, as in: show/create posts/topics outside of phpBB. Your scenario is different.

Re: group_id field in users table

Posted: Sun Jun 28, 2020 2:41 pm
by BarneyC
Mick wrote:
Sun Jun 28, 2020 7:15 am
BarneyC wrote:
Sat Jun 27, 2020 8:46 pm
Ok, so if a user is in newly registered group he also has to be in the registered group, even though you never want him to have the permissions associated with registered users? That seems counterintuitive
Not really, registered users have their permission set to allow them to perform what regular users do. Users in the Newly Registered User group (if enabled) have similar permissions but those permissions have ‘NEVER’ attributes for such things as posting (as in being on the mod queue) and PMing etc. All that happens once the user reaches the post threshold you set he drops out of the NRU, loses all the NEVERs and becomes a full member.
The point is that theres no point to being in both groups, since newly registered users are never considered to be registered users in terms of permissions or access.

Re: group_id field in users table

Posted: Sun Jun 28, 2020 3:20 pm
by david63
BarneyC wrote:
Sun Jun 28, 2020 2:41 pm
newly registered users are never considered to be registered users in terms of permissions or access.
Yes they are otherwise they would never be able to do anything.

I would suggest that you get an understanding of how the phpBB permission system works as it appears at the moment you are trying to rewrite it