After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 331946 - Evolution resets private/public and busy on all-day events
Evolution resets private/public and busy on all-day events
Status: RESOLVED DUPLICATE of bug 344927
Product: evolution
Classification: Applications
Component: Calendar
2.6.x
Other All
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2006-02-20 22:08 UTC by Paul Betts
Modified: 2013-09-13 00:53 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description Paul Betts 2006-02-20 22:08:26 UTC
Please describe the problem:
When creating calendar items that last all-day (or maybe other ones too, I'm not
sure), when changing the "show time as busy" and classification settings
(Public/Private/Confidential), setting one will change the other one, depending
on which order you set the properties.

Steps to reproduce:
1. Create an all-day event in Evolution
2. Set the confidentiality to Public (or a non-default value)
3. Clear the "Show time as busy"
4. Reopen the properties

Note that this may act as expected, I can't really find a consistent way to
trigger this bug but if you continually change, one at a time

a) The calendar it's registered on (I have Personal/School/Work)
b) The classification 
c) The busy/free

You'll run into a situation where it'll change more than one thing.

Actual results:
More than one option is changed, even though I only changed one option in the dialog

Expected results:
Only the option I changed should be altered.

Does this happen every time?
No, however it is fairly easy to trigger using the above steps.

Other information:
I'm not sure if this is related to the initial settings not being propagated to
 the dialog so the defaults are set, or if it's actually setting two things when
the calendar item is saved.
Comment 1 André Klapper 2006-07-11 00:30:10 UTC
tere are patches attached to bug 344927, so marking this one here as a duplicate. thanks for reporting it.

*** This bug has been marked as a duplicate of 344927 ***