Closed Bug 306692 Opened 15 years ago Closed 4 years ago

Simplify file menu (New calendar vs. Subscribe to calendar)

Categories

(Calendar :: Dialogs, defect, minor)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: lapsap7+mz, Unassigned)

References

Details

Attachments

(2 files, 4 obsolete files)

* "File" > "Open Calendar file" has no reaction

* "File" > "New Calendar file" has the same effect as
  "File" > "Subscribe to remote".  These last two items should be merged as one.
Unless we have a good, clear label to give to the New/Subscribe menu-items that
makes it clear to an average user what it does, I'm against combining them.  A
small, simple help might be to automatically select 'remote' when 'Subscribe' is
chosen.

'Open calendar file' should definitely disappear.
If New... and Subscribe... aren't supposed to be the same, of course they
shouldn't be merged.  But they need to display different things, or people would
think they're redundant.
What is the rationale behind eliminating the ability to easily browse to and
open local .ics files?

That seems like the natural thing to do when someone saves an ics file email
attachment, or they download an ics file because their browser isn't set up to
forward links to sunbird, --- in either case they want to look at the file, not
import it.

(The reason that New Local Calendar File and Open Local Calendar File are
separate in 0.2 is because the operating system provides different file picker
behavior depending on whether you're opening or creating a file.  
  If you're creating a new file (save as), then
    you're allowed to pick an non-existing name, and 
    if you pick an existing file, it warns you about overwriting.
  If you're opening a file, then 
    you're not allowed to provide a non-existing filename, and 
    you get no warning about overwriting when you pick an existing filename.
So both are needed.)

Maybe open calendar file could be combined with subscribe, however, as they are
both about adding existing files.  

(Commands to opening local and remote files were separate in 0.2 because local
files can use a file picker and urls cannot, and that distinction is familiar
from Firefox where there is both Open Location (url) and Open File (local) in
the File menu.)
*** Bug 310051 has been marked as a duplicate of this bug. ***
*** Bug 314563 has been marked as a duplicate of this bug. ***
*** Bug 319606 has been marked as a duplicate of this bug. ***
*** Bug 320176 has been marked as a duplicate of this bug. ***
Please could the severity of this bug be increased to at least Major? The 4 duplicates are all rated either normal or major but this one is only minor; it seems rather sneaky to close a major bug by marking it a duplicate of a minor one. 

Also the bug is present on the Linux version too. 

(In reply to comment #8)
> Please could the severity of this bug be increased to at least Major? The 4
> duplicates are all rated either normal or major but this one is only minor; it
> seems rather sneaky to close a major bug by marking it a duplicate of a minor
> one. 

There are fairly simple workarounds for all of the problems listed here, which means that the severity is correctly set to minor.  Adding P1, though, since the level of duplicates alone indicates that this is a very high-profile problem.

If no one takes this bug in the next week or so, I can probably find some cycles for it after calConnect, but that of course depends on what other priorities come up between now and then.

Assignee: mostafah → nobody
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
(In reply to comment #9)
> If no one takes this bug in the next week or so, I can probably find some
> cycles for it after calConnect, but that of course depends on what other
> priorities come up between now and then.
> 

What do we really want done here? Remove 'open calendar file'?
(In reply to comment #10)
> What do we really want done here? Remove 'open calendar file'?
> 
I agree with gekacheka that the Open Calendar File... option has many common use cases.  I think that needs to be more like the 0.2 behavior, where it opens a filepicker and adds the file picked to the list of calendar.

With regards to the other two problems, I think the New Calendar Wizard needs to accept an additional argument that contains a function to run when the dialog is loaded.  That way we can bypass the first screen and automatically select 'remote' when the user chooses 'Subscribe to Remote Calendar'.

(In reply to comment #9)
>...
> There are fairly simple workarounds for all of the problems listed here, which
> means that the severity is correctly set to minor.  Adding P1, though, since
> the level of duplicates alone indicates that this is a very high-profile
> problem.

Please could you elaborate on the simple workaround, because I haven't managed to find it?  I tried editing the properties of a calendar file to change its location to 
file:///blahblahblah/test.ics but it didn't work. Am I using the right URL format?

I know that I can import a calendar, but that is not what I want to do, because I want the calendar to be visible to other users. 
 
Thanks 
(In reply to comment #12)
> Please could you elaborate on the simple workaround, because I haven't managed
> to find it?  I tried editing the properties of a calendar file to change its
> location to 
> file:///blahblahblah/test.ics but it didn't work. Am I using the right URL
> format?

1.) Choose File->New Calendar file.
2.) Choose 'Remote'.
3.) Choose 'Webdav'.
4.) Type in the address of the file (beginning with file://)
5.) Fill in extra details (name/color)
6.) Enjoy.

You can test whether or not you're using the right URL format by trying to open the file in firefox.  The address in the addressbar in firefox should be the same as the address you type into the Location box in Sunbird.

Please use Mozillazine forums for support questions in the future.
(In reply to comment #13)
Thanks for the hint, that works great.

Going back to the matter of what the various menu items ought to do, my expectation (based on other applications) would be that "New Calendar" would only be used when creating a brand new empty calendar. "Open Calendar File" and "Subscribe to remote calendar" could possibly be merged, but I don't think it hurts to have both. Maybe they should execute the same dialogue but with different defaults. 

The dialogues should definitely be made more intuitive, but I imagine this is being worked on anyway. In particular if you select Local in the New Calendar
dialogue it should give you the option of creating an ICAL file in an arbitrary location  instead of the default hidden storage.sdb.
Attached patch Make 'Open Calendar' work, V1 (obsolete) — Splinter Review
This makes 'Open Calendar' launch a filepicker.
Attachment #207626 - Flags: first-review?(jminta)
Comment on attachment 207626 [details] [diff] [review]
Make 'Open Calendar' work, V1

+    var nsIFilePicker = Components.interfaces.nsIFilePicker;
Should probably be a const, not a var.

+    fp.init(window, getStringBundle().GetStringFromName("Open"), nsIFilePicker.modeOpen);

This only happens to work because we also include import-export.js (where getStringBundle() is defined) in calendar.xul.  I'd rather this code didn't depend on that file.

+    fp.appendFilter(gCalendarBundle.getString( "filterCalendar" ), "*" + ".ics" );
I know calendar.js doesn't have very consistent styling, but let's at least be consistent within this function.  (Don't put spaces around things in parens.)

+        var url = currentFile = fp.fileURL.spec;
Triple initializations are difficult to read, and I don't see any place where currentFile gets used.

+        // Handle if the calendar is already added
+        try {
+            calMgr.registerCalendar(openCalendar);
+        } catch(ex) {}
Failing silently here is going to confuse a lot of people.  Either let the error be thrown, or pop-up a nice error-message.

+        var captures = url.match(fullPathRegex);
This is a rather odd variable name to pick, why?

+        composite.addCalendar(openCalendar);
Why is this necessary?  I thought the composite registered an observer with the calMgr to listen for exactly these types of events.
Attachment #207626 - Flags: first-review?(jminta) → first-review-
Attached patch Make 'Open Calendar' work, V2 (obsolete) — Splinter Review
(In reply to comment #16)
> (From update of attachment 207626 [details] [diff] [review] [edit])
> +    var nsIFilePicker = Components.interfaces.nsIFilePicker;
> Should probably be a const, not a var.
> 

Fixed

> +    fp.init(window, getStringBundle().GetStringFromName("Open"),
> nsIFilePicker.modeOpen);
> 
> This only happens to work because we also include import-export.js (where
> getStringBundle() is defined) in calendar.xul.  I'd rather this code didn't
> depend on that file.
> 

Fixed

> +    fp.appendFilter(gCalendarBundle.getString( "filterCalendar" ), "*" +
> ".ics" );
> I know calendar.js doesn't have very consistent styling, but let's at least be
> consistent within this function.  (Don't put spaces around things in parens.)
> 

Fixed

> +        var url = currentFile = fp.fileURL.spec;
> Triple initializations are difficult to read, and I don't see any place where
> currentFile gets used.
> 

My mistake, that got left over during the coding-process =)

> +        // Handle if the calendar is already added
> +        try {
> +            calMgr.registerCalendar(openCalendar);
> +        } catch(ex) {}
> Failing silently here is going to confuse a lot of people.  Either let the
> error be thrown, or pop-up a nice error-message.
> 

try/catch removed

> +        var captures = url.match(fullPathRegex);
> This is a rather odd variable name to pick, why?
> 

That's the original variable name from the funcion in calendarCreation.js, so I figured I'd leave it like that, I could change it though, but I'm not sure to what

> +        composite.addCalendar(openCalendar);
> Why is this necessary?  I thought the composite registered an observer with the
> calMgr to listen for exactly these types of events.
> 

I thought that was necessary (I had to use it when doing that holiday-calendar-stuff for the calendar to be activated)
Attachment #207626 - Attachment is obsolete: true
Comment on attachment 207633 [details] [diff] [review]
Make 'Open Calendar' work, V2

Forgot to ask for review, sorry for the bugspam
Attachment #207633 - Flags: first-review?(jminta)
Comment on attachment 207633 [details] [diff] [review]
Make 'Open Calendar' work, V2

+    function srGetStringBundle() {
+        var strBundleService = 
+             Components.classes["@mozilla.org/intl/stringbundle;1"]
+                       .getService(Components.interfaces.nsIStringBundleService);
+        return strBundleService.createBundle("chrome://calendar/locale/calendar.properties");
+    }

This function is already defined, in calendar.js nonetheless.  You shouldn't redeclare it here.

+    if (fp.show() == nsIFilePicker.returnOK) {
Just a minor style nit, but I think it's better to reduce the amount of indenting you need to do when possible.  This could be
if (a != b) {
   return;
}
foo1();
foo2();

instead of

if (a == b) {
    foo1();
    foo2();
}

+        var captures = url.match(fullPathRegex);
Call it prettyName or something more indicative of what it is, just to make Venkman happier.
Attachment #207633 - Flags: first-review?(jminta) → first-review-
Attached patch Make 'Open Calendar' work, V3 (obsolete) — Splinter Review
This should fix those issues
Attachment #207633 - Attachment is obsolete: true
Attachment #207712 - Flags: first-review?(jminta)
Just my two cents:

+    fp.appendFilter(gCalendarBundle.getString("filterCalendar"), "*" + ".ics");

Why "*" + ".ics"? Why not write "*.ics" without another string add?

+    if (prettyName && prettyName.length >= 1) {
+        var name = prettyName[1];
+    }
+        
+    openCalendar.name = name;
+}

That code will fail if we do not hit the if-block. I think you either have to init variable 'name' first or move the 'openCalendar.name' assignment into the if-block.
(In reply to comment #21)
ssitter mostly read my mind here.

> +    fp.appendFilter(gCalendarBundle.getString("filterCalendar"), "*" +
> ".ics");
> 
> Why "*" + ".ics"? Why not write "*.ics" without another string add?
I think an argument can be made that the current code is a bit easier to read, emphasizing the 'ics' part, but I'll leave that up to redrenius.

> 
> +    if (prettyName && prettyName.length >= 1) {
> +        var name = prettyName[1];
> +    }
> +        
> +    openCalendar.name = name;
> +}
> 
> That code will fail if we do not hit the if-block. I think you either have to
> init variable 'name' first or move the 'openCalendar.name' assignment into the
> if-block.
> 
Indeed.  We should grab some sort of 'Untitled' string in an else block.

Attached patch Make 'Open Calendar' work, V4 (obsolete) — Splinter Review
This patch makes calendars with empty filename use 'Untitled Calendar' as name (the name is localizable).
Assignee: nobody → robin.edrenius
Attachment #207712 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #207734 - Flags: first-review?(jminta)
Attachment #207712 - Flags: first-review?(jminta)
This patch changes "*" + ".ics" to "*.ics" as per discussions on irc.
Attachment #207734 - Attachment is obsolete: true
Attachment #207735 - Flags: first-review?(jminta)
Attachment #207734 - Flags: first-review?(jminta)
Comment on attachment 207735 [details] [diff] [review]
[checked in] Make 'Open Calendar' work, V5

Thanks for the patch!  This helped me out immensely at calconnect.  r=jminta
Attachment #207735 - Flags: first-review?(jminta) → first-review+
Checked in the patch to make 'Open Calendar' work, leaving bug open to handle the other issues.  Reducing priority, since those aren't nearly as high-profile.

redrenius: If you're not planning to keep working on the other parts, please reassign this back to the default owner.
Priority: P1 → P3
(In reply to comment #26)
> redrenius: If you're not planning to keep working on the other parts, please
> reassign this back to the default owner.
> 

Reassigning to default assignee.

Assignee: robin.edrenius → mostafah
Status: ASSIGNED → NEW
Update summary from "Three "File" menu items have problems" to 
"Simplify file menu (New calendar vs. Subscribe to calendar)" to reflect remaining issues.
Summary: Three "File" menu items have problems → Simplify file menu (New calendar vs. Subscribe to calendar)
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
Target Milestone: --- → Sunbird 0.3
Not going to make the 0.3 train.

ssitter: Do you want this one to go with your other Menubar fun?
Target Milestone: Sunbird 0.3 → Sunbird 0.4
Target Milestone: 0.5
Blocking 0.5?
Flags: blocking-calendar0.5?
We're at the string freeze.  Bumping this to 0.7 and denying blocking-calendar0.5
Flags: blocking-calendar0.5? → blocking-calendar0.5-
Target Milestone: Sunbird 0.5 → Sunbird 0.7
Flags: wanted-calendar0.8?
Target Milestone: 0.7 → ---
Version: Trunk → unspecified
Attachment #207735 - Attachment description: Make 'Open Calendar' work, V5 → [checked in] Make 'Open Calendar' work, V5
It would be good to have this 0.8
Flags: wanted-calendar0.8?
Flags: wanted-calendar0.8+
Flags: blocking-calendar0.5-
This patch takes care of this issue by simply removing the "Subscribe to remote Calendar" menuitem. Asking for UI-review from Christian to get a feedback on whether this is the right choice for this bug.
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
Attachment #290094 - Flags: ui-review?(christian.jansen)
Attachment #290094 - Flags: review?(michael.buettner)
Sorry for the delay, I'll do the ui review as soon I can build on Leopard....
Comment on attachment 290094 [details] [diff] [review]
Remove "subscribe to remote calendar" from Sunbird File menu

r=mickey.
Attachment #290094 - Flags: review?(michael.buettner) → review+
I'm not sure if we really want to remove "Subscribe to remote Calendar" item, now. I support the approach, but we should focus on redesigning the whole calendar creation respectively subscription process. Removing only the entry point would only confuse people who are using that specific menu item....


In stead of removing "Subscribe to remote Calendar" we should optimize the wizard:
 - skip the first wizard step, and
 - hide the iCaledar, CalDav option.

Christian, IMO we should do it right the first time.

I seriously doubt that most fo our users do really distinguish between subscribing to an existing calendar and adding a new calendar. I believe, that for them it's simply "I want to add that cool holiday/football team/course schedule/etc. calendar on www.xyz.com" to my list of calendars.

And this use-case is pretty well-covered by our "new calendar" menuitem.

I believe what you want to improve is the problem with people choosing "CalDAV" instead of "ICS" or similar input errors. IMO this should be covered by adding appropriate calendar type autodetect code, not by adding/retaining additional menuitems.
What about renaming the new calendar item to "Add Calendar" ? This could mean both a new calendar and a subscription? Of course this would break the usual New-Open-Save-(Close) logic.
(In reply to comment #38)
> Christian, IMO we should do it right the first time.
> 
> I seriously doubt that most fo our users do really distinguish between
> subscribing to an existing calendar and adding a new calendar. I believe, that
> for them it's simply "I want to add that cool holiday/football team/course
> schedule/etc. calendar on www.xyz.com" to my list of calendars.
> 
Whats so wrong about differentiating between "New" (aka new calendar) and "Open" (aka subscribe to calendar). I do mentally make a difference between the two and most programs seem to offer these two options.
I think people might be worried about overwriting existing calendars if they choose "New calendar" while what they want to do is open an existing calendar.
Philipp, I don't think that renaming "New Calendar" to "Add Calendar" will buy us much. And staying with the current logic has advantages all by itself.

Sebastian, in Sunbird we already have a "Open Calendar..." menuitem, which allows to open local .ics files.
(In reply to comment #41)
> Sebastian, in Sunbird we already have a "Open Calendar..." menuitem, which
> allows to open local .ics files.
Hmm, but thats limited to local files. My main message should have been: I think there should be difference between creating a calendar and subscribing to an existing calendar. Wether its local or remote and wether you call it "open" or "subscribe" does not matter so much wrt this point.
There is no difference between creating a new calendar file and subscribing to an existing file for a normal user. For him it's all the same thing, he adds a new calendar to his Sunbird/Lightning installation.

The different semantics of creating a new calendar or subscribing to an existing calendar is something for computer-literate people like us, but nothing to molest normal users with.

I recommend the KISS principle here.
With that reasoning, word processors don't need to distinguish between 'open' and 'new' either. Yet they do. Until we can do user-testing, I think we should stick to what other applications do.
Priority: P3 → --
(In reply to comment #3)
>   If you're creating a new file (save as), then
>
Note the problem here. If "create new file" really means "save as",
then the wording of the interface is clearly not indicative of the
action that will result.

To add to that, I've been wracking my brains trying to figure out
how to share a calendar on a networked file system. I finally 
stumbled across the mechanism on a simlarly misnamed path:

  1. Choose "subscribe to calendar".
     The word "subscribe" clearly suggests an existing calendar,
     so I tried every option possible until finally reaching that
     one as a last resort.

  2. The dialog box /now/ gives the information that you can
     create a calendar to share on either the network or the
     file system.

I'm going to have to think more about the menu options really
ought to be, but at the moment the choices are pretty clearly
a bug in what otherwise is an exceptionally good interface and
superb functionality. (I see myself using this particular app
for a long, long time.)
(In reply to comment #41)
> Philipp, I don't think that renaming "New Calendar" to "Add Calendar" will buy
> us much. And staying with the current logic has advantages all by itself.
> 
On the contrary. The operation of "new" is well defined by every editor in existence, so expectation as to its behavior is well established. If I select "new", I expect to create a brand new calendar--a blank slate with nothing in it. 

Until I read this particular message, I had no idea that it would do anything other than that. If the operation is to add an existing calender to the ones
I'm viewing, then "Add" is a much better choice.

At this point, I'm beginning to see that the SunBird is not a "calendar", so much as a "Calendar Viewer", or "Calendar Aggregator". I think that expectation needs to be set up front in the first web page that explains what SunBird is. (Again, until reading this message, I had no idea it did that.)
(In reply to comment #38)
> 
> I seriously doubt that most fo our users do really distinguish between
> subscribing to an existing calendar and adding a new calendar. 
> 
Reading through these messages has led me to reconceptualize SunBird/Lightning as a "Calendar Aggregator". With that paradigm, "subscribe" is way better than "add", and both are a million times better than "new" (which should be removed until it implements behavior that is consistent with every other app in existence).  
Duplicate of this bug: 411825
Can't we just rename it to "New/Add Calendar"?
(In reply to comment #49)
> Can't we just rename it to "New/Add Calendar"?
> 
The first step is to identify the desired behaviors.
The next is to give them meaningful names.
The third is to see what people thing and respond to
their feedback.

I was astonished once again, today, when I chose "subscribe".
I'm on my system at home, and the idea was to point to the
calendar I made last night. Subscribe seemed like the right
choice. Wrong! "Subscribe" doesn't give me any option at all
to select an existing calendar. It /only/ lets me create one.
Egad. (The "open" method is obviously the one I want. My mental
model is improving.)

So maybe at this point I can hazard a guess as to step 1:
What behaviors are needed. Here's what I see so far:

  * Create a blank calendar, give it a name and a storage location
  * Open a calendar to edit it
  * Save an existing calendar under a new name
  * Share a calendar via publish/subscribe

There are also seem to be multiple technologies: local file
storage, WebDAV, and CalDAV (not familiar with that last one).

My initial matrix of those combinations, along with menu names
and behaviors, would then look something like this:

  NEW -- create a blank calendar
    location=network -- create it via WebDAV
    location=local   -- create it in the file system

  OPEN -- edit a calendar
    location=network -- access it via WebDAV
    location=local   -- access it from the file system

  SAVE AS -- save under a new name
    location=network -- via WebDAV
    location=local   -- via the file system

  PUBLISH -- create a read-only version that others can watch
    location=network -- create/update via WebDAV (CalDAV?)
    location=local   -- create .ics file
             
  SUBSCRIBE -- as with Publish

Notes:
 * I'm still unclear on what export is supposed to do. 
   But if it isn't converting to a new format, it should
   be named "Save As". Export and import are for conversions.

 * Not having a "Save" makes me nervous. I know. It really
   shouldn't be needed. I'm old school. I have hard time
   getting used to things that don't let Ctrl+S when I lean
   back and stop typing. If there were some way to allay my
   fears in the docs, a tooltip, or a daily tip, that would 
   be great.
   :_)

It occurs to me that there is another behavior that is insufficiently telegraphed by the interface. The "current" calendar is the one that events are saved to. But I only learned that by reading the bug reports. So once I attached to an existing calendar, I was supposed to remove the default. Of course, I forgot to do that, so events stored from one location were not visible in the other location.

The "surprising" behavior occurred there is nothing in the interface that tells me where an even is being saved. I like the idea that the app is a multi-calendar interface, but it seems to me that the logical extension of that behavior is that I might want to post an event to one of several calendars--one for my project, one for my home system, and one for an external group or activity, at a minimum.

In those circumstances, I need an interface that does more than rely on me to click the calendars tab and know that the top calendar in the list is the one that the event will be saved to. (Assuming that is the behavior. Lacking docs, there is no way to know.)

Some ways to improve the interface in this respect:
  * Preferences can have a setting "Currently saving to"
  * The title bar can display the save-target calendar
  * When creating an event, the dialog can have a drop down 
    with a list of potential targets
 
Note:
Did I mention that I really love this app? It also happens to 
be one I desperately need. Hence the extensive feedback.
Apologies for excessive verbosity.
Eric, your comment 51 is handled in bug 366914.
as for the third point raised in comment 51: this dropdown already exists in the event-dialog for a single calendar.
Not going to happen for 0.8.
Flags: wanted-calendar0.8+ → wanted-calendar0.8-
Flags: wanted-calendar0.8- → wanted-calendar0.9+
Comment on attachment 290094 [details] [diff] [review]
Remove "subscribe to remote calendar" from Sunbird File menu

Simon, is this patch still up for discussion, or obsolete?
This patch is still up for discussion, as I'm still waiting on a final decision here from Christian. He only commented once in this bug (comment 37), but never replied to my statement in comment 38.

Unless I get a ui-review- or ui-review+ I consider this bug to be open.
Flags: wanted-calendar0.9+ → wanted-calendar1.0+
Comment on attachment 290094 [details] [diff] [review]
Remove "subscribe to remote calendar" from Sunbird File menu

Bryan, could you take a look at this, please?

The use-case I'm trying Sunbird to optimize for is that most of our users do not distinguish between subscribing to an existing calendar and adding a new calendar. I believe, that for them it's simply "I want to add that cool holiday/ football team/ course
schedule/etc. calendar on www.xyz.com" to my list of calendars.

And this use-case is pretty well-covered by our "new calendar" menuitem.

Thanks for your time.
Attachment #290094 - Flags: ui-review?(chris.j.bugzilla) → ui-review?(clarkbw)
Comment on attachment 290094 [details] [diff] [review]
Remove "subscribe to remote calendar" from Sunbird File menu

I think what Philipp recommended in comment #39, "Add Calendar", sounds the best to me.  This text description seems right on for a use case and I can't see how "New Calendar" would fit in there.  

> I believe, that for them it's simply "I want to add that cool
> holiday/ football team/ course
> schedule/etc. calendar on www.xyz.com" to my list of calendars.

I agree that removing the "Subscribe" option is a win as well so I'd give a ui-r+ to remove subscribe and change the new to add.  I didn't see many arguments against using "Add Calendar..." but I might have missed them.

Also I think we should file a bug for Christian's concern in comment #37.  The menuitem text is important but the rest of the experience is really lacking as well.

minus for now until we have some discussion and reach agreement
Attachment #290094 - Flags: ui-review?(clarkbw) → ui-review-
I'm not going to work on this in the foreseeable future.
Assignee: bugzilla → nobody
Status: ASSIGNED → NEW
Sunbird is discontinued and not actively developed anymore.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
True, Sunbird is dead.  Let's move this to Thunderbird/Calendar and concentrate on it.
Status: RESOLVED → REOPENED
Component: Sunbird Only → Dialogs
Resolution: WONTFIX → ---
The reporzed issue isn't any im current TB. Please elaborate what's the TB issue here.
Flags: needinfo?(lapsap7+mz)
Whiteboard: [close me 2016-03-26]
Resolving incomplete. If you can provide the requested information, please feel free to reopen.
Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Flags: needinfo?(lapsap7+mz)
Resolution: --- → INCOMPLETE
Whiteboard: [close me 2016-03-26]
You need to log in before you can comment on or make changes to this bug.