Bric::ToDo - Bricolage To Do List
$Revision: 1.132 $
$Date: 2004/04/18 15:32:27 $
This document lists the items on Bricolage's To Do list.
Bricolage versions are determined by the types of changes required. Minor version numbers require no changes to the database schema (though data in the database can be added or changed, e.g, for new preferences), and require few changes to the libraries. The idea is to try to use the existing tools in the libraries and the database to do more in the UI, though minor changes to the libraries are allowed. Major version numbers, on the other hand, change when the database schema has been altered, or when the changes to the libraries are significant (including the addition of new libraries), or simply when significant features have been added.
At any one time, we will list the tasks that contributors have accepted for the next minor version and for the next major version. After that, we list other outstanding to do items in descending order of importance: ``High Priority Minor Items,'' ``High Priority Major Items,'' ``Low Priority Minor Items,'' and ``Low Priority Major Items.'' Developers who wish to volunteer to take on one or more of these tasks should announce their plans and version goal on the Bricolage Developers list <bricolage-devel@lists.sourceforge.net>. Contributions are welcome.
At the end of this document, the ``Blue Sky'' section features items that will likely never be done for the 1.x development of Bricolage, but we'd like to keep in mind as long term goals further down the line.
Limit
, Offset
, SortBy
, and SortDirection
parameters to
list()
in all classes. The SortBy
parameter can be either a string
identifying a single attribute (column) to sort by, or an array of attributes
(columns) to sort by Note that no matter what attributes are selected, the
object id column must always be the last sorted. Existing Order
and
OrderDirection
parameters should be considered aliases to be deprecated.
Limit
and Offset
can be added by using aggregates to ensure that all
objects are selected as single rows instead of multiple rows. See how Story,
Media, and Formatting do this now for examples. If this isn't possible, it can
be done using derived tables (Stephan Szabo is my hero for suggesting this --
I didn't even know it was possible!). Here's a quick example for person
objects:
select p.id, p.prefix, p.fname, p.mname, p.lname, p.suffix, p.active, m.grp__id FROM ( SELECT id, prefix, fname, mname, lname, suffix, active FROM person LIMIT 2 OFFSET 1) AS p, member m, user_member c WHERE p.id = c.object_id AND c.member__id = m.id and m.active = 1;
Obviously, you only change the query to use a derived table if the Limit
or
Offset
parameter is passed to list()
.
MySQL 4.1 also supports this feature, so I feel totally comfortable adding it to Bricolage and feeling like it's still portable to other databases.
Add media type associations to actions and allow users to select the media types they want associated with a particular action. Use the hard-coded action type media type associations as the default associations when a new action is created. Allow deactivation of objects to cascade into their associations. For example, if one wanted to delete an output channel, the UI should present the user with a list of objects it is associated with (story and media type elements, stories and media, destinations) and ask if the user is sure she wants to delete it and remove all of the associations. This might be tricky if, for example, a given story has only that one OC associated with it, or it is the primary output channel for a story.
eval
ed perl expression,
such as a DBI qeury to another database. Yes, this could be a security issue
(a serious one!), but we put the onus on the Bricolage administrator to ensure
that the people with access can't bollocks things up. We just have to make it
difficult for people to hack in and exploit such a field.
Add a Relational custom field option. This field would allow a a link to be
made to another arbitrary object in Bricolage. The custom field form would
have a select list of Bricolage object names (e.g., Story, User, Output
Channel, Event, etc.). When the user wishes to make the link, she's presented
with a manager-type search interface from which to find a pick the object she
wants.
Add user-created help for user-created fields (add a ``Help Text'' field to Form
Builder).
Make Session an object.
Add ordering to desks, such that their position in workflow can be ordered. This
will likely need some sort of attribute on the desks's membership in the group
for a workflow (since desks can be in multiple workflows).
Add a flag to the category object to indicate whether or not assets can be
associated with it, and then check that flag in the new asset profiles.
Add a flag to the category object to indicate whether or not the category is
allowed to have subcategories, and then check that flag in the category profile.
Add preference groupings (secret groups would probably work well) and present
the grouped preferences together in a profile. Then just list the preference
groups in the Preference Manager.
Add support for contributor contracts.
Add support for LDAP authentication.
Change way objects are deactivated (archived?) in the database such that, where
there are name uniqueness constraints, a new object can be created with the name
of a deleted one without any clashes (e.g., for Elements and Element Types).
Add file system-like asset browsing (especially for templates and media).
Create a different way of distinguishing which desks are shared and which are
not, rather than relying solely on the desk name.
Add explicit directory (a.k.a. story index) support.
Add object so that a new group can start with the settings (including
permissions) of an existing group.
Allow Element Types to be subelements. This means that all elements of a
particular type will be subelements, so that if you add or remove elements of
that type, they will automatically be subelements of whatever element for
which the type is defined.
Add specification for whether Elements added as Subelements of another are
``Required'' or not -- just as we currently do for fields in an Element.
Create separate sand box for previewing stories with templates while templates
are under development -- that is, without deploying them.
Add support for individual user preferences that can override (some) global
preferences. (Also add group-level prefs?)
Allow multiple files to be associated with a single media asset (e.g., when
there's an image, a thumbnail, a high-res version, etc., all essentially for the
same asset).
Implement keyword synonyms. This might include support for various meanings
among keywords and/or support for a prefered keyword among a group of
synonymous keywords. Past versions of Bricolage (pre 1.3.2) included an
incomplete implementation that you might use as inspiration.
David Wheeler <david@wheeler.net>
Bric, Bric::Changes.