[Phpgroupware-tracker] [bugs #5719] upgrade losses all prefs and can only save default or forced

[Johnson]

This mail is an automated notification from the bugs tracker
 of the project: phpGroupWare.

/**************************************************************************/
[bugs #5719] Latest Modifications:

Changes by: 
                Johnson <address@hidden>
'Date: 
                Mon 12/01/2003 at 11:12 (Canada/Eastern)

------------------ Additional Follow-up Comments ----------------------------
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








/**************************************************************************/
[bugs #5719] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=5719>
Project: phpGroupWare
Submitted by: Chris Weiss
On: Fri 10/03/2003 at 13:23

Category:  API - Preferences
Item Group:  0.9.16RC1
Severity:  9 - Blocker
Priority:  9 - Immediate
Resolution:  Works for me
Assigned to:  skwashd
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: Mon 12/01/2003 at 11:12       By: jecinc
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



-------------------------------------------------------
Date: Mon 12/01/2003 at 10:04       By: jecinc
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

-------------------------------------------------------
Date: Fri 10/31/2003 at 20:16       By: mexico
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

-------------------------------------------------------
Date: Wed 10/22/2003 at 04:10       By: skwashd
This is now fixed? right?

-------------------------------------------------------
Date: Tue 10/14/2003 at 21: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: Tue 10/14/2003 at 20: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: Tue 10/14/2003 at 16: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: Tue 10/14/2003 at 14: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: Tue 10/14/2003 at 14: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: Fri 10/10/2003 at 17: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: Fri 10/10/2003 at 16: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: Fri 10/10/2003 at 14: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: Fri 10/10/2003 at 10: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: Fri 10/03/2003 at 19: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: Fri 10/03/2003 at 18: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: Fri 10/03/2003 at 14: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.














For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=5719>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/