bugphpGroupWare - Bugs: bug #5719, upgrade losses all prefs and can...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #5719: upgrade losses all prefs and can only save default or forced

Submitted by:  Chris Weiss <cw>
Submitted on:  Fri 03 Oct 2003 05:23:29 PM UTC  
 
Item Group: 0.9.16RC1Category: API - Preferences
Severity: 3 - NormalPriority: 5 - Normal
Status: Works For MePrivacy: Public
Assigned to: Dave Hall <skwashd>Open/Closed: Closed
Component Version: SVNOperating System: None
Reproducibility: NonePlanned Release: None
Fixed Release: 

(Jump to the original submission Jump to the original submission)

Sun 04 Dec 2005 09:49:25 AM UTC, comment #17:

This no longer seems to be an issue so I am closing it

Dave Hall <skwashd>
Project AdministratorIn charge of this item.
Mon 01 Dec 2003 04:12:55 PM UTC, comment #16:

As suggested, changing
Would you like phpGroupWare to cache the phpgw info array ?:
to no (in the admin, site configuration screen) seems to make the prefs save properly

Not really a fix, but at least it's usable

Johnson <jecinc>
Mon 01 Dec 2003 03:04:01 PM UTC, comment #15:

I think jarg's evaluation of the upgrade problem is correct but he went the wrong direction

oProc and db point to two different things

However, I think all the ->db-> in that function should be changed to ->oProc-> instead of the other way around

The reason is explained in your installed docs at:
phpgroupware/setup/doc/setup3-1.html
"This flag is a decision on whether to alter the database or the schema_proc array. The tables_baseline file above is loaded by setup prior to running your upgrade routines. If the current installed version is greater than the current upgrade routine, we don't need to alter the database yet. But schema_proc instead alters the $phpgw_baseline array in memory. The maintenance of this array is done even when we do alter the database. Once our version number in the test array matches the currently installed version of an application, real work on the tables begins. "

The oProc lines will not be committed to the db in all cases. I found this to be necessary when doing the contacts update scripts.

Anyway, having them all ->db-> or ->oProc-> will fix this particular problem, but switching all to ->oProc-> will prevent encountering another problem

This still leaves the prefs not being saved during normal use problem

Johnson <jecinc>
Sat 01 Nov 2003 01:16:13 AM UTC, comment #14:

latest CVS from 1.11.2003 01:30 GMT
when in site configuration is set

Would you like phpGroupWare to cache the phpgw info array ?:
to yes, prefs is not working (either forced/default/users)
when set to no, prefs working fine

and second bug ... after upgrade, prefs is still missing, dosn't matter of setting phpgw caching

Peter Bodnar <mexico>
Wed 22 Oct 2003 08:10:30 AM UTC, comment #13:

This is now fixed? right?

Dave Hall <skwashd>
Project AdministratorIn charge of this item.
Wed 15 Oct 2003 01:08:57 AM UTC, comment #12:

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

Dave Hall <skwashd>
Project AdministratorIn charge of this item.
Wed 15 Oct 2003 12:50:30 AM UTC, comment #11:

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.

Michael Totschnig <totschnig>
Tue 14 Oct 2003 08:23:51 PM UTC, comment #10:

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??

Jonathan Rivera <jarg>
Tue 14 Oct 2003 06:50:41 PM UTC, comment #9:

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)

Chris Weiss <cw>
Project Administrator
Tue 14 Oct 2003 06:03:04 PM UTC, comment #8:

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.

Jonathan Rivera <jarg>
Fri 10 Oct 2003 09:44:07 PM UTC, comment #7:

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.

Dave Hall <skwashd>
Project AdministratorIn charge of this item.
Fri 10 Oct 2003 08:27:05 PM UTC, comment #6:

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?

Chris Weiss <cw>
Project Administrator
Fri 10 Oct 2003 06:59:55 PM UTC, comment #5:

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)

Anonymous
Fri 10 Oct 2003 02:45:41 PM UTC, comment #4:

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.

Michael Totschnig <totschnig>
Fri 03 Oct 2003 11:44:18 PM UTC, comment #3:

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

Chris Weiss <cw>
Project Administrator
Fri 03 Oct 2003 10:39:55 PM UTC, comment #2:

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.

Dave Hall <skwashd>
Project AdministratorIn charge of this item.
Fri 03 Oct 2003 06:16:25 PM UTC, comment #1:

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.

Chris Weiss <cw>
Project Administrator
Fri 03 Oct 2003 05:23:29 PM UTC, 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.

Chris Weiss <cw>
Project Administrator

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 5 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sun 04 Dec 2005 09:49:25 AM UTCskwashdSeverity6 - Security=>3 - Normal
  Priority9 - Immediate=>5 - Normal
  Open/ClosedOpen=>Closed
Wed 22 Oct 2003 08:10:30 AM UTCskwashdStatusNone=>(Error - Not Found)
  Assigned toNone=>NA

Back to the top


Powered by Savane 3.1-cleanup1