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

[nobody]

=================== BUG #5719: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5719&group_id=509

Changes by: Michael Totschnig <address@hidden>
Date: ven 10.10.2003 à 14:45 (GMT)

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





=================== BUG #5719: FULL BUG SNAPSHOT ===================


Signalé par: cw                       Projet: phpGroupWare                  
Signalé le: ven 03.10.2003 à 17: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: ven 10.10.2003 à 14: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: ven 03.10.2003 à 23: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: ven 03.10.2003 à 22: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: ven 03.10.2003 à 18: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.




La liste CC est vide


Il n'y a aucun fichier attaché actuellement


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/