View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0008381 | mantisbt | administration | public | 2007-09-21 11:00 | 2016-07-11 15:34 |
Reporter | joshb | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | confirmed | Resolution | open | ||
Product Version | 1.1.0a4 | ||||
Summary | 0008381: Setting Configuration Option Fails | ||||
Description | Setting the configuration option for default_home_page for a specific member produces the entered result for all users despite the configuration setting entered. | ||||
Steps To Reproduce | Set specific member ie: guest/anonymous | ||||
Additional Information | Have only tried this with default_home_page but I suspect this may be the case with any setting entered. | ||||
Tags | No tags attached. | ||||
That's not exactly the bug. The bug is that in the login.php file the config_get functions are located before the authentication so the default home page is not the one configured for a specific user. In the login.php file the line "$f_return = gpc_get_string( 'return', config_get( 'default_home_page' ) );" must be removed and added into the following if structure:
|
|
Does this show the same behavior when returning to the Mantis site with the permanent login cookie? ie, if the Mantis login url is http://www.example.com/mantis/login_page.php - log yourself in, then visit http://www.example.com/mantis and see where it takes you. Does that obey the per-user configuration as it should, or does it still have problems? |
|
Patch applied but this still does not solve the issue. The issue lies in part that the login_page.php applies a return string to the url based on the current logged in settings, which would be guest/anonymous. That return string is overriding any configuration changes being applied by the db. I'm not sure there is a way to solve this because of the way it's set ie: anonymous users being logged into the system. I don't understand why viewers would need to be logged in at all. If the project is set to public why would you need to be logged in to view it? That simply doesn't make any sense. Much like a forum system or any other web membership website for that matter - unless you wish to participate there's no need to be logged in. I'm not sure why it was set up this way but since it is - there may not be a way to get this done without killing the current anonymous session that exists, then forwarding them to the login_page so that no return url is created. |
|
Yes - after exiting the site completely when logged in - then returning to the url the per-user config works as expected. It's only on login that it fails to operate properly. |
|
Ok, so there is no solution. |
|
Well that's an excellent answer. Why didn't I think of that? |
|