=================================
|| Horde Development TODO List ||
=================================

- Horde_Label api. We need to replace the 'categories' code in Nag,
Mnemo, etc. that's duplicated in lots of places with a more
centralized, more flexible solution. Prominent problem is that labels
are tied to preferences and can't be edited by anyone with edit
permissions to the Share - and that they can't really be done without
shares.

The new API should store labels in Categories, to get them out of
preferences, and to let anyone with proper permissions edit them
(perms checking will be done outside of the Labels class). Labels will
also be able to have attributes such as colors. A UI will be provided
for managing them on a keyword basis (app:shareid, or app:addressbook
/ app:addressbook:owner for Turba).

- Add a $registry->switchUser() / pushUser() / other user-context
switching method, that'd load the correct prefs, etc.?

- Implement some sort of non-SQL persistent categories backend that
can be the default backend so that people don't get non-persistent
categories. Get rid of the null backend; we pretty much _need_
persistent categories for Horde 3.0's functionality to work as
advertised.

- Implement admin/deleteUser methods in applications' APIs to delete
user specific data.

- Implement a Horde_Lock class that sits on top of categories and
provides locking of any object in the Horde system, like Links
provides relations between any object and Perms provides permissions.

- Add a /services/groups/ section. Include public group homepages,
including any information marked public for the group (let the members
list be marked public/group only/admin only), add group administrators
(just a flag for users), add the ability to show all calendars/other
shares that a group has permissions to, allow creating a new
calendar/poll/etc. for a group.

- Add the ability to break out DataTree group_uids into their own
tables (one table per group).


$Horde: horde/docs/TODO,v 1.11 2004/02/21 17:40:31 chuck Exp $