After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 343809 - users & groups: should have some mention than a session restart is required to apply a group change
users & groups: should have some mention than a session restart is required t...
Status: RESOLVED WONTFIX
Product: gnome-system-tools
Classification: Deprecated
Component: users-admin
2.15.x
Other Linux
: Normal enhancement
: 2.30
Assigned To: Carlos Garnacho
Carlos Garnacho
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2006-06-04 10:56 UTC by Sebastien Bacher
Modified: 2012-11-24 20:28 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Patch for GST 2.30 in Ubuntu Lucid Beta (4.77 KB, patch)
2010-04-13 17:36 UTC, Xiegai Shan
needs-work Details | Review
simple demo for patch above (66.73 KB, image/png)
2010-04-13 17:38 UTC, Xiegai Shan
  Details

Description Sebastien Bacher 2006-06-04 10:56:17 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/gnome-system-tools/+bug/48262

"I'm running Ubuntu Dapper Drake, and created a user called "svn" using the GUI tool found under System->Administration->Users and Groups. I noted that along with this user called "svn" a group of the same name was consequently auto-created. I pressed ok to close.

Next, I decided to add my own account, "ballen", to the group "svn".

Once again, I opened the Users and Groups GUI, then found the group "svn" under the Groups tab. I doubleclicked the "svn" group, then added the "ballen" user to the "svn" group. I then pressed ok to close and closed the Users and Groups GUI.

I quickly discovered that my "ballen" account did not have the priveleges of being a member of the "svn" group. When I typed the "id" command while logged in as "ballen", the "svn" group was nowhere among the list.

After a reboot, the change took effect, and the id command showed "ballen" to be a member of "svn".

Hopefully, you will consider this a bug. It caused me considerable consternation as I suspect it will others.

Thanks!
..."
Comment 1 Sebastien Bacher 2006-09-08 10:09:20 UTC
Still an issue with 2.15.3
Comment 2 zrfsiia02 2007-06-26 06:04:07 UTC
The user has to log in again (not reboot) before changes in their groups take effect. This also happens if the group is changed at the command line. This is therefore not a bug in Gnome. However it might be a good idea to tell this somewhere in the users-admin interface.
Comment 3 Xiegai Shan 2010-04-13 17:36:17 UTC
Created attachment 158624 [details] [review]
Patch for GST 2.30 in Ubuntu Lucid Beta
Comment 4 Xiegai Shan 2010-04-13 17:37:29 UTC
I think I have fixed the bug in the following way: 
After the user succeed to add/edit/delete in the group settings, when the user click "close" to quit the "Manage Group" dialogue, the application will prompt the user for the options "Reboot later by myself" and "Reboot now".

The files attached are the patch for GST 2.30.0 in Lucid Beta and a picture for simple demo.
Comment 5 Xiegai Shan 2010-04-13 17:38:36 UTC
Created attachment 158625 [details]
simple demo for patch above
Comment 6 zrfsiia02 2010-04-13 20:29:38 UTC
As I said, a reboot is not necessary. The user only needs to log out and log in again, and the new session will have the privileges.

(Actually the user doesn't even need to log out if (s)he opens multiple sessions. The sessions opened after the change will have the privileges, the ones opened before won't.)

I'm not a fan of unnecessary reboots.
Comment 7 Milan Bouchet-Valat 2010-04-14 09:55:29 UTC
Xiegai: I think it would be better to show a label in the main dialog, just below the "Enable account" warning. There you can first show the label as soon as changes have been performed, and possibly a logout button, if you want. This way, you don't need to create a new variable to know whether groups were edited or not. Quite easy and clean to do.

And that's much nicer from a user interaction POV - showing an additionnal dialog when closing the tool isn't very nice.

Note that there are other places where you need to check that changes to groups are made: when a user account type is changed, and when privileges are edited in the Advanced Settings dialog. But you only need a gtk_widget_show() there.

One question is whether we should show the warning for all users, or only for the user that was edited. The latter would require a new (hidden) column in the users list.
Comment 8 Milan Bouchet-Valat 2010-04-14 11:12:58 UTC
BTW, the string shouldn't be so imperative. People shouldn't log out, they just need to log out if they "want their changes to take effect". That's how update-manager says it when you've installed a new kernel, I think you should give it a look at adapt that sentence.
Comment 9 André Klapper 2012-11-24 20:28:25 UTC
According to its developer(s), gnome-system-tools is not under active development anymore. Functionality has been mostly integrated into GNOME Control Center / "[System] Settings".

It is unlikely that there will be any further active development.

Closing this report as WONTFIX as part of Bugzilla Housekeeping - Please feel
free to reopen this bug report in the future if anyone takes the responsibility
for active development again.