Always grant 'authenticated user' role

With INSERT INTO role (rid, name) VALUES (2, 'authenticated user'); in database definition, a simple define (DRUPAL_AUTHENTICATED_RID, 2); would suffice instead of the db function. Otherwise, very cool patch.

moshe, my problem is that you add a query to every page served to non-anon users. IIf someone has a real weirdo setup, then (s)he can correct the define.

I think I don't like this patch. First, it adds overhead, second, here on drupal.org I on occassion ban users by taking "authenticated" user away and granting the "restricted users" role. We could of course change "authenticated users" to have only a minimal set of permissions but then we'd need to grant additional rights to every new user.

One can of course question the wisdom of having a "restricted users" role and not blocking the users directly.

I think we should instead make sure that at least one checkbox of that checkbox set is checked.

Moshe: the problem is not that I have this setup, but drupal.org has it. :P

I dont know what propted the introduction of the "restricted user" role. if we find out that we don't need it, we can go with this patch.

The 'restricted user' role was introduced to block registered users from posting. We could have blocked these users as well. Still, punishing certain users without having to block them might be a sensible use case?

If we have 'DRUPAL_AUTHENTICATED_RID' we should have 'DRUPAL_ANONYMOUS_RID' as well and use it across the code. Example:

  if ($rid != 0 && $rid != DRUPAL_AUTHENTICATED_RID) {

Also, please depricate:

function _user_authenticated_id() {
  return db_result(db_query("SELECT rid FROM {role} WHERE name = 'authenticated user'"));
}

Some more observations:

In my role table is an anonymous user too. I guess that should be cleaned up as well?

mysql> select * from role;
+-----+--------------------+
| rid | name               |
+-----+--------------------+
|   1 | anonymous user     |
|   2 | authenticated user |
|   3 | administrator      |
+-----+--------------------+

In the users_roles table are registered users as well:

mysql> select * from users_roles where uid = 1;
+-----+-----+
| uid | rid |
+-----+-----+
|   1 |   2 |
|   1 |   3 |
+-----+-----+

And, maybe it's worthwhile at the same time, to fix the role names 'Authenticated user' and 'Anonymous user' which are untranslatable.. :-)

Haven't test it. Code looks good.

Does $key need to be escaped?

-            $row[] = array('data' => form_render($form['checkboxes'][$rid][$key]), 'align' => 'center');
+            $row[] = array('data' => form_render($form['checkboxes'][$rid][$key]), 'align' => 'center', 'title' => $key);

Just make sure that we do not double escape some titles. I am OK with the change. But, as you are promising a new patch, I changed the status.

Question.. will this patch prevent the logintoboggan module from working? That module allows users to instantly sign up and pick their own passwords without having to futz around in their e-mail, thus increasing usability.

If you use this option, users are added to a "pre-authorized" group of your choosing to give them a set of minimal permissions (better than anon but less than 'authenticated user') until such time that they've validated their e-mail address and then get bumped up to 'fully' authenticated user. But if authenticated user applies for ALL logged in users, it seems we would lose this option for functionality.

@webchick: I think the better solution would be to do it the other way around. Make authenticated user a minimalist set of permissions, and something like "validated user" the "real" role. Then use hook_user() to automatically put a user into "validated user" on email validation.

Similar solution for Drupal.org and the "restricted but not banned" issue that killes mentioned. It might even be good to generalize "put into role on user creation" functionality into a module, if someone hasn't done it already.

This gets a conceptual +1 from me, although I've not looked at the code yet.

Committed to HEAD. Thanks.

Original patch did not remove INSERTs into user_roles in database.pgsql

Rerolled from the top.

Committed to HEAD. Thanks.

Sorry, shouldn't these statements be removed as well?

 INSERT INTO role (name) VALUES ('anonymous user');
 INSERT INTO role (name) VALUES ('authenticated user');

i discovered this thread because a small patch i submitted for user.module (see http://drupal.org/node/47735 for details) applies cleanly in 4.6 but fails to patch against the HEAD . one "side effect" of this whole discussion about 'authenticated user' is that the db_query() inside user_access() was "simplif[ied]... a bit by removing JOIN". well, that broke my nice clean patch from working in HEAD. ;) cvs annotate on the modified db_query() line in HEAD lead me here... (side note: drupal and drupal.org is great... i love the fact that the cvs log messages in your repository include node ids about the thread that lead to the patch -- if only we were so well organized and coordinated where i work).

i can see that removing an unnecessary JOIN in the default case is a good thing, but i'm wondering if any of you user.module experts would comment on my other thread.

thanks much!
-derek

umm..still experiencing this on 5.12, new users don't have the 'authenticated user' role attached by default.

Am i the only?

I am also facing the same problem, can someone please tell me how can I use this patch. that is where should I copy it.

Thanks.

hi all,
i am totally new to the drupal environment, how to set user permission on the user registration. can any one address me please
with regards,
hari