Bric::ToDo(3p)        User Contributed Perl Documentation       Bric::ToDo(3p)



NAME
       Bric::ToDo - Bricolage To Do List

VERSION
       $LastChangedRevision$

DATE
       $LastChangedDate: 2006-03-18 01:26:34 +0100 (Sat, 18 Mar 2006) $

DESCRIPTION
       This document lists the items on Bricolage's To Do list.

OVERVIEW
       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.

   High Priority Minor Items
       o   Add ability to reverse the sort order of items on desks.

       o   Add "Checkout" button to the "View" screens for stories, media, and
           templats. It must be careful about permissions in the same way that
           comp/workflow/manager/dhandler currently is. That is to say, in
           order for the button to be displayed, the user must have EDIT
           permission to the asset. If the asset isn't currently in workflow,
           the user must have RECALL permission to the asset or to the assets
           on the start desk in the current workflow, and at least EDIT
           permission to the assets on the start desk.

       o   Add Checkin & Shelve (And Checkin & Publish?) to the dropdown menu
           on My Workspace.

       o   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.

       o   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.

       o   Resolve the "Adding Element and hitting Cancel" issue (See
           <http://bugzilla.bricolage.cc/show_bug.cgi?id=3>).

       o   Add interface to select from existing keywords for associating with
           assets.  Note that support Keyword Groups will have to be returned
           to the API.

       o   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).

       o   Write distribution documentation.

       o   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").

       o   Add ability to "undeploy" templates without deactivating them.

       o   Add option to the installation system to always use the defaults
           and never prompt the user.

       o   Disallow the Find Stories and Find Media interfaces from searching
           for and returning all of the stories and media in the database.
           [David]

       o   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).

       o   Adjust listManager and desk interfaces so that they remember the
           field use to sort items until the end of a session.

       o   Add a "preview" action to the Workflow SOAP interfaces. It will
           work just like "publish" except, of course, that it "previews" and
           doesn't checkin the assets or remove them from desks or workflows.

       o   Implement a funky hack so that we can have story components like
           /story.mc inherit based on the location to which we're publishing
           (/foo/bar/story), not the actual location of the component.

       o   Add media thumbnail to desk view (is there room?).

   High Priority Major Items
       o   Add browser-based UI for scheduled burning/syndication.

       o   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.

       o   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.

       o   Since elements and element types aren't really deleted from the
           database and you can't change an element's type once it has been
           created, the default templates are very restrictive.  For example,
           I wanted to change the pull quote element from an Inset to a new
           general Subelement type, but when you delete pull_quote and try to
           recreate it as a Subelement, it fails because "pull_quote" already
           exists.

           The installer should have an option to not install the default
           elements.  This seems easy enough by moving those SQL commands to a
           separate file and executing them based on whether the user opts to
           install them.

           Better yet, if there was a way to import elements and element types
           (through SOAP?[1]), there could be no default, but several
           different pre-made element sets that the user could choose to
           import right after installation depending on what type of site they
           wanted (daily newspaper, montly magazine, normal website, etc.).

       o   Revamp the element system. See the proposed functional
           specification here:
           <http://bricolage.cc/docs/design/ElementRevision.html>.

       o   Add support for Instant messaging (using Jabber server) in Alerts.

       o   Port installation system to use Module::Build.

       o   Add "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 Template 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.

       o   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.

       o   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.

   Low Priority Minor Items
       o   Add interface for editing Contact Types.

       o   Create Makefile for distribution engine only.

       o   Add UI support for Organizations.

       o   Add UI support for addresses.

       o   Add HTML Cleaning Action.

       o   Link contributors to their assets -- provide a link in the
           Contributor Manager and/or the Contributor Profile).

       o   Add preferences for listManagers to indicate whether they should
           default to expand or narrow behavior.

       o   Add command-line argument to bric_dist_mon that will kill the
           currently-running instance.

       o   Add autopopulation of video media type properties, such as codec,
           bit rate, fps, length, etc. Use a tool such as Video::Info.

       o   Add thumbnails for videos (using a snap from the first frame?) and
           other media files (using icons).

       o   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.

   Low Priority Major Items
       o   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.

       o   Add a Relational custom field option. This field would allow 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.

       o   Add user-created help for user-created fields (add a "Help Text"
           field to Form Builder).

       o   Make Session an object.

       o   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).

       o   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.

       o   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.

       o   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.

       o   Add support for contributor contracts.

       o   Add support for LDAP authentication.

       o   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).

       o   Add file system-like asset browsing (especially for templates and
           media).

       o   Create a different way of distinguishing which desks are shared and
           which are not, rather than relying solely on the desk name.

       o   Add explicit directory (a.k.a. story index) support.

       o   Add object so that a new group can start with the settings
           (including permissions) of an existing group.

       o   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.

       o   Add specification for whether Elements added as Subelements of
           another are "Required" or not -- just as we currently do for fields
           in an Element.

       o   Create separate sand box for previewing stories with templates
           while templates are under development -- that is, without deploying
           them.

       o   Add support for individual user preferences that can override
           (some) global preferences. (Also add group-level prefs?)

       o   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).

       o   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.

       o   Add a max size option to media Element profiles, for setting a per-
           element size cap on uploaded media.

   Blue Sky
       o   Add support for Java templates.

       o   Add basic project management. Tie project tasks to workflow desks.

       o   Add support for concurrent checkouts, including support for
           conflict resolution.

       o   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.

       o   Integrate with Subversion.

       o   Integrate with WebDAV (Slide? mod_dav?).

       o   Add full-text indexing of the database. See
           <http://techdocs.postgresql.org/techdocs/fulltextindexing.php> for
           one approach using PostgreSQL.

       o   Add stronger type checking.

       o   Add thorough directory (LDAP, NDS, ADS) integration, including
           group and permission management.

       o   Add support for document translation (e.g., Word, QuarkXPress,
           Acrobat, etc.).

       o   Add support for skins -- different colors, etc, probably via
           preferences.

       o   Allow Elements to be previewed before they're added.

       o   Add permission granularity down to the user, property, field, and
           attribute levels.

       o   Add reporting, where reports can be templated and saved for
           particular users, or to be shared between users.

       o   Allow items to move through different workflows and/or desks in
           parallel.

AUTHOR
       David Wheeler <david@justatheory.com>

SEE ALSO
       Bric, Bric::Changes.



perl v5.12.2                      2006-03-17                    Bric::ToDo(3p)
