Allow preference for default, separate tasks calendar

RESOLVED DUPLICATE of bug 366914

Status

Calendar
Provider: CalDAV
--
enhancement
RESOLVED DUPLICATE of bug 366914
9 years ago
4 years ago

People

(Reporter: captainmish, Unassigned)

Tracking

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.7) Gecko/2009030423 Ubuntu/8.10 (intrepid) Firefox/3.0.7
Build Identifier: 0.9

Enable a distinct tasks calendar as default, so that when tasks are being added, the "tasks" calendar is selected as the calendar to save to.

Zimbra uses distinct event and todo calendars, and it is difficult when using this with sunbird/lightning to rememer to choose the correct calendar to use for tasks or calendars.

See:
http://bugzilla.zimbra.com/show_bug.cgi?id=30787


A preference to just set the default calendar for tasks would help a lot.

Reproducible: Always

Steps to Reproduce:
1. Open calendar
2. Add a task
Actual Results:  
Selected calendar is the last selected, or the top of the list

Expected Results:  
If we are creating a task/TODO, use the task/TODO calendar as default.

Comment 1

9 years ago
I suggest not to take this in core but it would be something for an addon. Zimbra has it's own way of dealing with tasks and events apparantly, we adhere to the specs in the rfc. 

Reading the mentioned bug, this is for caldav specifically, is the supported methods set on a per-calendar basis for caldav in Lightning? This means it wouldn't be possible to create a task in a caldav calendar which announces only the VEVENT-method.
Component: Preferences → Provider: CalDAV
QA Contact: preferences → caldav-provider
Duplicate of this bug: 543765

Comment 3

8 years ago
This is not just a Zimbra issue.  In a shared environment, it is sometimes desirable to have tasks remain private even though the calendars may be shared.  My workaround is to have a separate, non-shared, tasks calendar.  But you still need to be careful into which calendar the task is placed.

Expected behaviour would allow the user (reader) of the calendar to designate whether tasks were shown, and also allow the Owner to determine if authorized users saw the tasks or not.

Comment 4

8 years ago
(In reply to comment #1)
> I suggest not to take this in core but it would be something for an addon.
> Zimbra has it's own way of dealing with tasks and events apparantly, we adhere
> to the specs in the rfc. 
> Reading the mentioned bug, this is for caldav specifically, is the supported
> methods set on a per-calendar basis for caldav in Lightning? This means it
> wouldn't be possible to create a task in a caldav calendar which announces only
> the VEVENT-method.

I think you're looking at this wrong.  It's not a BUG with anything (zimbra or lightning).  Or with Zimbra not sticking with the RFCs. It's just an enhancement request.  And it really has nothing to do with CALDAV or ICS etc specifically.

FOR EXAMPLE:

Zimbra's web client stores Tasks in a different DAV share on the server:
https://<server>/dav/<user>/Tasks
vs
https://<server>/dav/<user>/Calendar

This is the same with the .ICS files on the zimbra server.

Heck even if Zimbra wasn't involved at all, what if you want a Seperate calendar (stored locally) for TASKS than you do for Calendars.

Right now I have Lightning storing my TASKS on the https://<server>/dav/<user>/Calendar calendar, and it works fine, but obviously Zimbra won't show any of those tasks on the web client side (because it doesn't look for tasks in there).

I'm just thinking that by allowing the user to specify different default calendars for each view (calendar, task, etc), and OPTIONALLY, the ability to even HIDE some calendars from specific views, we can make lightning more robust to handle different situations.

Comment 5

8 years ago
Created attachment 425867 [details]
rough draft UI suggestion for selecting default/hidden calendars for Calendar / Tasks tabs.

Comment 6

8 years ago
The proposed UI and ability to select default calendars for event and tasks is certainly a step in the right direction.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 366914
You need to log in before you can comment on or make changes to this bug.