Table of Contents
KOrganizer can store (and retrieve) events, journal entries and to-dos using various methods, and to different locations. Each of these locations is called a calendar resource.
KOrganizer supports calendar files based on standards such as iCalendar and vCalendar natively (adding them as new resources), but you can import the data (merge) into an existing resource and open the file in a new window too. Importing files in the format used by the old ical application is also supported.
You can export your data as a web page, as an iCalendar or vCalendar file. These files are supported by most scheduling applications. The web page can be used to publish your calendar and to-do list on the web or on the local network.
In this chapter, we will explain how to manage your calendar, using the resources, import and export actions and the get hot new stuff scheme.
KOrganizer uses a local file, usually
as its default resource. But this is not your only option: there are several
other resources you can add: groupware servers, journal entries as blogs,
network files, etc. If you use more than one resource, KOrganizer
can be configured to use the default
resource or ask which resource to use when saving new events, to-dos or
journal entries. KOrganizer will seamlessly merge the items from
two or more resources in the views.
The default resource is a good choice for many use cases, but you may want to use another resource, especially if you use a supported groupware server. Please ask the server administrator for the information required to configure the groupware resource, including free/busy information publishing and retrieving. Access to free/busy information allows an event organizer to take the attendee's calendar into consideration when adding him to the event's attendee list.
Besides calendar storage, groupware servers typically offer contacts, mail and free/busy information storage. Therefore, some of the resources discussed here may be related to other resources from KMail and KAddressBook (the mail and contacts components of Kontact), or to the free/busy settings in the main configuration.
Please note that KOrganizer group scheduling communication is based on a peer to peer email standard. This means that you do not need a groupware server to use it!
Procedure 3.1. Adding a New KOrganizer Resource
Open KOrganizer's settings dialog with → and select the Calendars tab from the General page.
Alternatively open the context menu in the Calendar Manager sidebar with a mouse button click and select Add Calendar...
If the Calendar Manager is not displayed on the sidebar, choose the → → menu item to display it.
Press the button to add new resources to the list of available resources.
Check or uncheck the resource box to enable or disable it.
Later, if you want to edit or delete a resource, select it on the Calendar Manager sidebar and press to delete it or to modify it.
Among the existing resources, you can find in KOrganizer:
- Birthdays & Anniversaries
Provides access to birthday and anniversary dates of contacts in your address book as calendar events.
- DAV groupware resource
Resource to manage DAV calendars and address books (CalDAV, GroupDAV).
- ICal Calendar File
Loads data from an iCal file.
- KDE Address Book (traditional)
Loads data from a traditional KDE address book resource.
- Kolab Groupware Server
Provides access to Kolab groupware folders on an IMAP server (IMAP accounts need to be set up separately).
- Open-Xchange Groupware Server
Provides access to the appointments, tasks, and contacts of an Open-Xchange groupware server.
Alternatively, you can configure the KOrganizer resources (plus all other KDE resources), in the System Settings, using the KDE Resources configuration module.
Provides access to calendars stored in Akonadi calendar folders.
- Journal in a blog
Add this resource to be able to read your blogs as journal entries, directly from blog servers, such as blogger and drupal.
- Bugzilla To-do List
Add this resource to load bugzilla open bugs as to-dos. This resource is based on the kbugbuster application, and uses its bug cache information. Bugzilla is an open source bug tracking system.
If you are a developer working on a project that uses bugzilla, you can use this resource to view as to-dos the open bugs of the applications or libraries you are interested in (they are called “products” and/or “components” in bugzilla). This resource is available as part of the KDE Software Development kit.
- Calendar in Local File
Add this resource to be able to save (and load) your events, to-dos and journal entries to a local file. The file can be in the iCalendar or in the vCalendar standard format. KOrganizer uses this resource by default, storing your calendar information under
- GroupDav Server (e.g. Open Groupware)
If you have access to a server that supports the GroupDav protocol, add this resource in order to be able to save (and load) events and to-dos to the server. To add the resource, you will need to know the server URL, your user name and your password. The GroupDav protocol supports the storage of contacts, so you may want to add and configure the KAddressBook resource too.
- Calendar on IMAP Server via KMail
If you have access to a server that shares calendar data via IMAP, add this resource in order to be able to save (and load) events, to-dos, free/busy information and journal entries to the IMAP server. To enable IMAP access, you will need to configure KMail first, then add the KOrganizer resource. Also, since you are using KMail to contact the server, KOrganizer will open KMail automatically, and use it to access your data. The “IMAP server via KMail” schema supports the storage of contacts, so you may want to add the KAddressBook resource too.
Most IMAP servers can be used to hold calendar and address book resources, allowing you to access your data from just anywhere! If you are a user looking for a simple way to access and manage your groupware information, this is a simple and very efficient solution.
To use this resource, it is necessary to configure KMail first. Choose the → menu item. Click the Accounts icon in the configure dialog sidebar and add the IMAP server as a disconnected IMAP incoming account. Now click the Misc icon in the sidebar and click the Groupware tab to enable and configure the IMAP resource folder options. Only then you can add the KOrganizer (and KAddressBook) resources. For more information on configuring KMail, consult the KMail handbook.
A more complete implementation of this schema is the Kolab Server. This groupware implementation offers additional features for system administrators, such as support of mixed client environments (Microsoft® Outlook(R), KDE PIM and web mail), a web administration interface, shared address book, email server, etc. As of June 2005, the groupware servers that implement the “Kolab 1” and “Kolab 2” protocols are the Kolab server, version 1 and 2, and the Citadel server (Kolab 1 only). An up to date list can be obtained at the Kolab website.
The most practical way to configure the access to a Kolab server is to use the kolabwizard wizard application. You can start it from the command line prompt:
- Calendar in Local Directory
Add this resource to be able to save and load your events, to-dos and journal entries from a local folder. Each calendar item will be saved in a separate file, inside the folder.
Since there is only one file per event, to-do, or journal entry, KOrganizer does not need to parse one big calendar file, sometimes with thousands of items when saving or loading, just one single calendar item. Also, in case of file corruption, you will lose only one calendar item, not the whole calendar.
- Calendar in Remote File
Add this resource to be able to save and load your events, to-dos and journal entries from a remote file. There are two main advantages of keeping your calendar data in a remote server: you can access your data even if you are away from your computer, and you can let other people (for instance, a secretary) view it. KOrganizer keeps a cache of the data locally.
You can configure the resource to be read only, keeping the remote file untouched. In this case, you won't need to supply a Upload to location, just a Download from location for the remote file. If you plan to use a writable remote resource, you will have to supply both locations. The reason to have separate locations, is that some servers may have an upload queue, a place where you need to put the upload file, different from its final location. In most cases, if you have write access to the remote file, the Upload to and Download from file locations should be the same.
It is important to understand that the remote file resource does not add or remove individual items from the remote file, it simply saves the remote file over local cache when downloading and save the local cache over the remote file when uploading. Therefore, if the resource is read only, it makes sense to set the Automatic Reload option to a Regular interval, but if not (if the resource is writable), it is recommended to reload the file only before starting to edit it, by setting the Automatic Reload option to On startup, and to save it before exiting, by setting the Automatic Save option at least to On exit, or better yet, if you have a fast and stable connection to the remote file, set it to On every change to avoid data loss.
If you add, change or remove events, journal entries or to-dos and reload the remote file, all your local changes will be lost, and the file will revert to its previous state. This can happen in different scenarios (for instance if the system crashes, KOrganizer will reload the remote file on the next start, if you set the Automatic Save to Never, or if you set the Automatic Reload to a regular interval). If you plan to use a calendar resource in writable mode, make sure that your connection is stable, configure the resource to save the file on each change (or at frequent intervals), and do not reload the file at regular intervals.
A related, but opposite problem, is that two users cannot safely edit the same remote file at the same time, because the remote file resource does not offer a conflict resolution mechanism. For instance, if someone else changes (and saves) the remote file, after you loaded it, and at some later time you save the file, his changes will be lost.