Bric::ToDo - Bricolage To Do List
$Revision: 1.96.2.4 $
$Date: 2003/04/28 22:01:51 $
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.
Give users the option to reactivate deleted templates when they try to create a template that already exists in the database as a deactivated template. [David]
Create category browser so that, in interfaces where users have to navigate categories (e.g., when creating subcategories, or when assigning an asset to a category), they can do it hierarchically, rather than have to look at a long-ass list of all categories.
When clicking "New" for an existing contributor, allow choice of Contributor Type, and then role. Right now, if you want an existing contributor to be a contributor of a different type, you have to create a new person, and this duplication is bad.
When adding a new person, have user search for existing persons first to ensure that the person doesn't already exist. That is, when adding a new user, it could be that the person being added is already in the system as a contributor, so the new user object can be based on the person object underlying the contributor object. Similarly, when adding a new contributor, the person being added could have an existing person record as an existing contributor or user.
Write context-sensitive help for those pages that are still missing it.
Resolve the "Adding Element and hitting Cancel" issue (See http://bugzilla.bricolage.cc/show_bug.cgi?id=3).
Add Keyword Management interface to centrally manage keywords. Also add interface to select from existing keywords for associating with assets. Note that support Keyword Groups will have to be returned to the API.
Create backup and restore scripts that make it easy to do, especially given the difficulties of importing a PostgreSQL database dump from Bricolage (Sam has more details on this).
Write distribution documentation.
Add preferences and the code to enforce them to allow admins to specify that keywords follow certain rules, such as being all lowercase, or to exclude certain words (e.g., About.com excludes the keyword "about.com").
Add ability to "undeploy" templates without deactivating them.
Add option to the installation system to always use the defaults and never prompt the user.
Add search story/media element type to the Find Stories and Find Media interfaces. This feature would be in the Advanced search interface, but for those who want to have it present all the time, see the next item.
Add preference to make advanced search in Find Stories and/or Find Media the default search form when you go to those screens.
Disallow the Find Stories and Find Media interfaces from searching for and returning all of the stories and media in the database. [David]
Update exception handling to allow for option to send error details to a valid email address or URI. The error page (500.mc) would have a form with all the details in hidden fields, and a button. When the button is pressed, the info in the form would either be sent to the specified email adddress or to the specified URL (on the assumption that that URL would process the form data).
Add a checkbox to the Bulk Edit page. When the box is checked, line wrapping will be preserved as pasted (e.g., when pasting in poetry). When it's not checked, the lines will be unwrapped into a single line (as happens now), so that they wrap inside the textarea box nicely. It will be unchecked by default to keep the interface basically the same as it is now.
The installation system should allow the PostgreSQL database to exist on a separarate machine. Currently only a local database will work.
Replace use of Text::Iconv with Encode?
Remove check_uri() bottleneck in Story.pm and Media.pm. Create a table with two columns in it, one for story IDs and one for URIs, and put all of the URIs in it. Then we could just query against that table to compare URIs. All the possible URIs for a story would have to be included in the table, for all combinations of category and output channel Do the same for media.
Move callbacks to modules that subclass MasonX::CallbackHandler.
Add browser-based UI for scheduled burning/syndication.
Add browser-based UI for mass publication and distribution. This will primarily be useful for template redesigns that need to be applied to a large set of pages or a whole site.
Add better tools for handling special characters (e.g., high ASCII, Latin-1 letters with umlauts and accents and such). May need to select a character set to be associated with output channels, and convert characters based on the character set.
Revamp the element system. See the proposed functional specification here: http://bricolage.cc/docs/design/ElementRevision.html.
Add support for Instant messaging (using Jabber server) in Alerts.
Add an email mover. There should be one that will simply mail the contents of an output, and one that will send the contents as an attachment (or attachments, if there are several files).
Port installation system to use Module::Build.
Add desk paging, such that the assets on a given desk (or My Workspace) can be viewed across a series of pages.
Add "Check all" button that uses JS to select all the select checkboxes on a publish desk and My Workspace. There's a button in My Alerts that can be copied for this purpose.
Add interface for editing Contact Types.
Create Makefile for distribution engine only.
Add support for Organizations.
Add support for addresses.
Add HTML Cleaning Action.
Add X?HTML Validation Action.
Link contributors to their assets -- provide a link in the Contributor Manager and/or the Contributor Profile).
Add preferences for listManagers to indicate whether they should default to expand or narrow behavior.
Add command-line argument to bric_ftpd that will kill the currently-running instance.
Add command-line argument to bric_dist_mon that will kill the currently-running instance.
Add autopopulation of video media type properties, such as codec, bit rate, fps, length, etc. Use a tool such as Video::Info.
Change template deployment to not append the output-channel post_path to the template filename. Currently the burners have hacks in them to look in the post_path for templates but ultimately this should be fixed the right way. If you choose to accept this mission you'll need to write an upgrade script to correct template entries in the database and move deployed templates on the filesystem.
Add a callback option to custom fields. This feature would allow custom Perl code to be associated with the field, and to be executed when the field is filled in by a user. This would perhaps be the best way to allow fields to be "customized," e.g., when a field needs to be looked up in another database via the DBI. 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 optional code field to custom fields. This feature will allow a select list to offer as options the values returned from evaled 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.
Add support for Java templates.
Add basic project management. Tie project tasks to workflow desks.
Add support for concurrent checkouts, including support for conflict resolution.
Add support for display of deltas between versions -- something like what CVSWeb does, in terms of allowing editors to see what has changed between versions of an asset.
Integrate with Subversion.
Integrate with WebDAV (Slide? mod_dav?).
Add full-text indexing of the database. See http://techdocs.postgresql.org/techdocs/fulltextindexing.php for one approach using PostgreSQL.
Add stronger type checking.
Add thorough directory (LDAP, NDS, ADS) integration, including group and permission management.
Add support for document translation (e.g., Word, QuarkXPress, Acrobat, etc.).
Add support for skins -- different colors, etc, probably via preferences.
Allow Elements to be previewed before they're added.
Add permission granularity down to the user, property, field, and attribute levels.
Add reporting, where reports can be templated and saved for particular users, or to be shared between users.
Allow items to move through different workflows and/or desks in parallel.
David Wheeler <david@wheeler.net>