[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only
From: |
nobody |
Subject: |
[Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only save default or forced |
Date: |
Tue, 14 Oct 2003 21:08:57 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030618 Debian/1.3.1-3 |
=================== BUG #5719: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5719&group_id=509
Changes by: Dave Hall <address@hidden>
Date: Wed 10/15/03 at 11:08 (Australia/Melbourne)
------------------ Additional Follow-up Comments ----------------------------
This bug is a BASTARD!
IMHO the two issues are seperate, but also related.
I am waiting on someone to finish some intensive testing on this one. We think
we have both parts fixed.
I hope to commit it sometime today. Sorry for the delay, but I don't want to
make things any worse - if that is possible.
Jarg how are things looking at your end?
Cheers
Dave
=================== BUG #5719: FULL BUG SNAPSHOT ===================
Submitted by: cw Project: phpGroupWare
Submitted on: Sat 10/04/03 at 03:23
Category: API - Preferences Bug Group: 0.9.16RC1
Severity: 9 - Critical Priority: None
Resolution: None Assigned to: None
Status: Open Component Version: CVS
Platform Version: None Reproducibility: None
Summary: upgrade losses all prefs and can only save default or forced
Original Submission: Upgraded .14 to .16, prefs table is now empty.
Default and Forced prefs save fine all other prefs do not save at all.
Adding a prefs row manualy then loading the prefs screen causes the new row to
be deleted, just LOADING the screen, not even saving it.
Follow-up Comments
*******************
-------------------------------------------------------
Date: Wed 10/15/03 at 11:08 By: skwashd
This bug is a BASTARD!
IMHO the two issues are seperate, but also related.
I am waiting on someone to finish some intensive testing on this one. We think
we have both parts fixed.
I hope to commit it sometime today. Sorry for the delay, but I don't want to
make things any worse - if that is possible.
Jarg how are things looking at your end?
Cheers
Dave
-------------------------------------------------------
Date: Wed 10/15/03 at 10:50 By: totschnig
the last comments seem to indicate that the bug that is discussed here,
concerns primarily what happens with the preferences during the update process.
I just wanted to add that my comments were not concerned with this problem but
with the second problem the original submission talks about, i.e. that
preferences can no longer be saved. So to avoid confusion, maybe this bug
should be splitted in two.
-------------------------------------------------------
Date: Wed 10/15/03 at 06:23 By: jarg
yes i change $GLOBALS['phpgw_setup']->oProc->next_record() into
$GLOBALS['phpgw_setup']->db->next_record() , all $GLOBALS['phpgw_setup']->oProc
into $GLOBALS['phpgw_setup']->db
and this is my question, is correct to use $GLOBALS['phpgw_setup']->db instead
$GLOBALS['phpgw_setup']->oProc??
-------------------------------------------------------
Date: Wed 10/15/03 at 04:50 By: cw
what do you mean "changed by db"?
made $GLOBALS['phpgw_setup']->oProc->next_record() into
$GLOBALS['phpgw_setup']->db->next_record() ? (that would be changed TO db)
-------------------------------------------------------
Date: Wed 10/15/03 at 04:03 By: jarg
in my upgrade from .14 to .16 i missing my prefs too, but i see the scritp and
view this in line 648 from tables_update.inc.php:
$GLOBALS['phpgw_setup']->db->query("SELECT * FROM old_preferences");
while ($GLOBALS['phpgw_setup']->oProc->next_record())
i change the oProc by db and i have my phpgw_preference table with all my
preferences migrated, only i have a question, i change all the oProc by db,
but, is this correct??
really i need to read more about schema proc, please comment.
-------------------------------------------------------
Date: Sat 10/11/03 at 07:44 By: skwashd
This bug is very annoying. I have been working on how to fix it. I think the
function will be removed. I just need to make sure removing anything won't
break something else.
-------------------------------------------------------
Date: Sat 10/11/03 at 06:27 By: cw
unless setup changes the cache setting to NO, then this is not verifiable. The
one test upgrade I have has it set to NO now, and probably did before too. the
database dump has no entry at all concerning cache in phpgw_config so I'd
assume that means it was set to no?
-------------------------------------------------------
Date: Sat 10/11/03 at 04:59 By: None
By comparing two installations, I observed that this bug depends on the value
of "Would you like phpGroupWare to cache the phpgw info array ?". if it is no,
preferences work, if it is yes they do not.
(Sorry for not being logged in (this is totschnig). I am on a foreign computer
without access to my credentials)
-------------------------------------------------------
Date: Sat 10/11/03 at 00:45 By: totschnig
This bug is very ennoying. I am still convinced that fonction
verify_basic_settings is not worth the trouble. Why save these default values
into the preferences table, which normally should carry the users
*preferences*. If you need default values they should either be returned by the
read_repository function, or applied by the code that uses the preference. This
would be safer design in my opinion: For example the limit_query function in
the database classes should apply a default value for the maxmatch preference,
if it is not set. This would avoid to have the strange consequences we see when
the verify_basic_settings function misbehaves as it does at the moment.
-------------------------------------------------------
Date: Sat 10/04/03 at 09:44 By: cw
the issue seems to be unique to upgraded installs, I can't figure out why. Far
as I can tell this shouldn't be a problem anyway, and if it is it seems it
should be fixed in read_repository where it's attempting to load def and forced
anyway
-------------------------------------------------------
Date: Sat 10/04/03 at 08:39 By: skwashd
Hi cw,
I put this change in. I will explain the logic with notes in that code
section. This was designed to fix a bug where default/forced prefs were being
ignored.
if ($preferences_update)
{
$user_id = $this->account_id;//get correct_id
//capture prefs
$user_prefs = $GLOBALS['phpgw_info']['preferences'];
$this->account_id = -1;//default values user
$df_prefs = $this->read_repository();//get d/f values
if(is_array($df_prefs))//are there any d/f values
{
foreach($df_prefs as $app_name => $app_prefs)//loop
{
if(is_array($app_prefs))//any d/f for that app?
{
foreach($app_prefs as $pref => $ignore)
{
//we don't need to save def/forced pref values
unset($user_prefs[$app_name][$pref]);
}
}
}
}
$this->account_id = $user_id;//reset user id to cur user
$this->update_data($user_prefs);//update the prefs
$this->save_repository();//save it
//re read the prefs
$GLOBALS['phpgw_info']['preferences'] =
$this->read_repository();
}
This was a fix for
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5321&group_id=509
I am not sure why this is causing a problem, as the uid is updated post unset
loop.
-------------------------------------------------------
Date: Sat 10/04/03 at 04:16 By: cw
For some reason read_repository is getting called 2 times, the second time is
with $this->account_id = -1. This causes all the read in prefs to be wiped and
reloaded with only the forced prefs, but then save_repository is still called
with the correct user ID and saves NOTHING .
read_prepository automaticaly handles default and forced prefs when a user's
prefs are loaded, and as far as I can tell a prefs page can only be loaded by
calling up a users prefs. Therefore read_prepository should /never/ be called
with anything besides a valid user id.
The only culprit i have located so far is line 675 in
phpgwapi/inc/class.preferences.inc.php:
$this->account_id = -1;
removed it and everything is fine.
CC list is empty
No files currently attached
For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5719&group_id=509
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only save default or forced, (continued)
- [Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only save default or forced, nobody, 2003/10/03
- [Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only save default or forced, nobody, 2003/10/03
- [Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only save default or forced, nobody, 2003/10/10
- [Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only save default or forced, nobody, 2003/10/10
- [Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only save default or forced, nobody, 2003/10/10
- [Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only save default or forced, nobody, 2003/10/10
- [Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only save default or forced, nobody, 2003/10/14
- [Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only save default or forced, nobody, 2003/10/14
- [Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only save default or forced, nobody, 2003/10/14
- [Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only save default or forced, nobody, 2003/10/14
- [Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only save default or forced,
nobody <=
- [Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only save default or forced, nobody, 2003/10/22
- [Phpgroupware-tracker] [bug #5719] upgrade losses all prefs and can only save default or forced, nobody, 2003/10/31