|
[
Permalink
| « Hide
]
Petr Skoda added a comment - 04/Apr/08 08:16 PM
Is the authenticated user role selected in $CFG->defaultuserroleid ?
No. I set this, and problem resolved.
Probably system behavour silently chages during upgrade, which causing those problems. Petr, we have had a bunch of reports about problems with this setting changing to "guest" and so.
If the solution is always to change it to authenticated user... what's the key about allowing it to be selected? Also... could we, as one step in upgrade... check for it (if empty or so) and set it to default? I guess a lot of people don't "save" the upgrade form on upgrade (I've had some reports about other missing settings like emoticons...) in recently upgraded to 1.9 sites. Ciao Yes, it seems many sites have ended up with $CFG->defaultuserroleid == guest after an upgrade which causes all kinds of serious problems.
Can you make sure it gets set to Authenticated User by default, Petr? hi,
the problem was in 1.7.x - I suppose that any site that went through that version is affected, the reason why it was not switched in 1.8 was that it sort of worked which is not the case in 1.9 anymore. going to fix it somehow... Hello, Petr
You wrote "the problem was in 1.7.x - I suppose that any site that went through that version is affected" I can say that our site was upgraded from 1.6.x straight to 1.8.1. and later to 1.9beta during Bugathon and so on, and it was affected. patch committed into cvs,
thanks for the report Hi Petr,
was reviewing this and it seems that you are changing those "guest" roles to NULL (instead of "Authenticated role". Is that the expected behaviour? Shouldn't we default to the authenticated one? That's the only point preventing me to close this, as the list now is properly skipping guest roles to be selected and everything else seems to be working ok. Ciao the set_config('xxx', null) deletes the value, right?
/**
yup, yup. That's not the question I wanted to do, hehe.
Some comments above Martin commented "Can you make sure it gets set to Authenticated User by default, Petr?", and that's not current behaviour. Just that. Ciao Yes, can we set it to "Authenticated User" by default? Most admins aren't going to read all the 100 new settings, they just accept defaults. And for this setting it almost always needs to be set to Authenticated User otherwise strange stuff happens.
I does set it to authenticated user by default. Only if guest found there, it is unset and the admin is notified that he/she should chose some other role, but again the authenticated role is preselected in upgrade settings.
I do not think we should just switch that setting without informing admins, because even the guest role might have some overrides or customisations. Well,
I think that Petr's approach is also valid if it's IMPOSSIBLE to bypass the settings page (i.e. if somebody tries to continue with installation... the new settings page is showed again until saved). And will show, in any case the default "authenticated user" in any case. But... if it's possible to bypass the settings page, then we MUST set it in upgrade (instead of unsetting). so, they key here is... does the new settings page in upgrade REQUIRE to be saved to continue upgrade? Ciao The missing settings get shown again if you go to admin/index.php
hmm, maybe I could add a new hack to test the new settings once for admin after login and redirect to upgradesettings if needed, this would also solve the problem with bumping of main version when settings are added in modules. I'm OK with it as it is now I think, but the hack sounds good too.
reclosing then and filing new issue for the proposed hack
Closing. Thanks!
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Closed
Blocker
Users can't update their profiles or passwords, thought in Authenticated user and Student roles these capabilities Allowed.
 |
|
