phpgroupware-tracker
[Top][All Lists]
Advanced

[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: Fri, 10 Oct 2003 16:27:06 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030514 Debian/1.3.1.x.1-2

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

Changes by: Chris Weiss <address@hidden>
Date: Fri 10/10/03 at 15:27 (America/Chicago)

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



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


Submitted by: cw                      Project: phpGroupWare                 
Submitted on: Fri 10/03/03 at 12: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: Fri 10/10/03 at 15: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/03 at 13: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/03 at 09: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/03 at 18: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/03 at 17: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/03 at 13: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/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]