phpGroupWare - 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
Submitter: | Chris Weiss <cw> | ||
Submitted: | Fri 03 Oct 2003 05:23:29 PM UTC | ||
Category: | API - Preferences | Item Group: | 0.9.16RC1 |
Severity: | 3 - Normal | Priority: | 5 - Normal |
Status: | Works For Me | Privacy: | Public |
Assigned to: | skwashd | Open/Closed: | Closed |
Component Version: | SVN | Operating System: | None |
Reproducibility: | None | Planned Release: | None |
Fixed Release: |
Jump to the original submission
Sun 04 Dec 2005 09:49:25 AM UTC, comment #17: |
Dave Hall <skwashd> |
Mon 01 Dec 2003 04:12:55 PM UTC, comment #16: As suggested, changing
|
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
|
Johnson <jecinc> |
Sat 01 Nov 2003 01:16:13 AM UTC, comment #14: latest CVS from 1.11.2003 01:30 GMT
|
Peter Bodnar <mexico> |
Wed 22 Oct 2003 08:10:30 AM UTC, comment #13: This is now fixed? right? |
Dave Hall <skwashd> |
Wed 15 Oct 2003 01:08:57 AM UTC, comment #12: This bug is a BASTARD!
|
Dave Hall <skwashd> |
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.
|
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
|
Jonathan Rivera <jarg> |
Tue 14 Oct 2003 06:50:41 PM UTC, comment #9: what do you mean "changed by db"?
|
Chris Weiss <cw> |
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:
|
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> |
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> |
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.
|
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> |
Fri 03 Oct 2003 10:39:55 PM UTC, comment #2: Hi cw,
|
Dave Hall <skwashd> |
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 .
|
Chris Weiss <cw> |
Fri 03 Oct 2003 05:23:29 PM UTC, original submission:
Upgraded .14 to .16, prefs table is now empty.
|
Chris Weiss <cw> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 5 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2005-12-04 | skwashd | Severity | 6 - Security | 3 - Normal | |
Priority | 9 - Immediate | 5 - Normal | |||
Open/Closed | Open | Closed | |||
2003-10-22 | skwashd | Status | None | None | |
Assigned to | None | None |
Powered by Savane 3.13-02a9.
Corresponding source code
This no longer seems to be an issue so I am closing it