Bug 47127

Summary: korganizer doesn't save todo list column header prefs.
Product: [Retired] Red Hat Linux Reporter: Mike A. Harris <mharris>
Component: kdepimAssignee: Bernhard Rosenkraenzer <bero>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-07-13 12:52:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Mike A. Harris 2001-07-03 12:42:28 UTC
Description of Problem:
In Korganizer the todo list on the left side has default column headers
"Summary   Priority    Due Date".  I drag and drop priority to the first
column and it works.  If I exit korganizer and restart it has forgotten
my column reordering.  This makes the whole point of customizing the
order useless.  Using save settings in the pulldown menu also doesn't help.

How Reproducible: 100%

Steps to Reproduce:
1. View TODO/Week view
2. Drag the priority column over to the left in front of "Summary"
   and let go.  It now moves there in front.
3. Hit save settings in the pulldown menu at top.
4. Quit Korganizer and restart.

Actual Results:
Columns have reset to factory defaults.  ;o)

Expected Results:
My settings are remembered.  I shouldn't have to manually tell it to
save them either it should just remember that I moved the columns like
user friendly Windows applications would.  ;o)

Additional Information:
Windows 95 CD's make good coasters for protecting your desk against
hot drinks.

Comment 1 Mike A. Harris 2002-06-22 04:57:48 UTC
Korganizer basically sucks, and seems unmaintained upstream.  No real point
in keeping this bug open as it probably isn't a high priority item to fix,
and not likely to get fixed upstream.  Evolution and other software seem
much better for this sort of thing.

In lieu of a CLOSED->REPORTER_DOESNT_CARE_ANYMORE resolution, I've chosen