[Phpgroupware-tracker] [Bug #1857] changes to Forced and Default preferences appearently have no effect

[nobody]

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

Changes by: Rick Bartels <address@hidden>
Date: 2003-Jan-05 15:06 (GMT)

------------------ Additional Follow-up Comments ----------------------------
I am not the original submitter of this bug report, but my default preferences 
now appear to be working as they should as in when I make a change to a setting 
and submit, they are there when I go back to check. It did not help my 
timestamp bug but now that setting stays at what I set it to. I have another 
bug open on the timestamp issues.
Rick Bartels



=================== BUG #1857: FULL BUG SNAPSHOT ===================


Submitted by: None                      Project: phpGroupWare                   
Submitted on: 2002-Dec-02 18:49
Category:  API - Preferences            Bug Group:  0.9.14.001 release          
Severity:  5 - Major                    Priority:  High                         
Resolution:  None                       Assigned to:  skwashd                   
Status:  Open                           Component Version:  None                
Platform Version:  Linux - RedHat       Reproducibility:  Every Time            

Summary:  changes to Forced and Default preferences appearently have no effect

Original Submission:  First, I realize this may not be a big issue on the 
surface, but this is delaying a rollout that would have been done over the 
weekend.

I log in as eadmin (the admin user) and click preferences, and default or 
forced preferences.  Then click Change Your Settings.  I make change to 
linux-at-work.de theme. and click submit.

When I come back to forced preferences, the changes are not there.  Nor do they 
take effect when current or new users log in

MySQL backend, Apache 2.0.40, RedHat 8

Follow-up Comments
*******************

-------------------------------------------------------
Date: 2003-Jan-05 15:06             By: biker
I am not the original submitter of this bug report, but my default preferences 
now appear to be working as they should as in when I make a change to a setting 
and submit, they are there when I go back to check. It did not help my 
timestamp bug but now that setting stays at what I set it to. I have another 
bug open on the timestamp issues.
Rick Bartels

-------------------------------------------------------
Date: 2002-Dec-31 22:52             By: skwashd
I think forced prefs is now fixed in cvs.

Can you let me know if it is fixed.

Cheers

-------------------------------------------------------
Date: 2002-Dec-21 06:54             By: skwashd
Hey Adam,

I have not beeen able to get forced prefs working sucessfully.  On the other 
hand default prefs do work.  I used them for adding about 30 new users last 
week :)

Default prefs only work for new users, not ones previously created.

Hey biker,

The default tz issue, imho this the way it should work, ig the user can set it, 
it should default to 0 - which means it will be in the same tz as the server.  
Altering that will create a tz offset from the server, not gmt.

Cheers

-------------------------------------------------------
Date: 2002-Dec-05 00:10             By: biker
I have also noticed this with time settings in both default and forced 
preferences. I am using pgsql backend and am using   the same apache and redhat 
versions. When trying to set timezone defaults to User Selectable, they return 
as 0. I have also reported a time settings bug in a previous bug report 
(16??-timezone and speed issues)

-------------------------------------------------------
Date: 2002-Dec-02 18:52             By: None
Submitted by Adam Long
address@hidden


CC List
*******

CC Address                          | Comment
------------------------------------+-----------------------------
address@hidden                | 



No files currently attached


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=1857&group_id=509