CVS edit link for druido

I have written a module for Drupal 6.x (not tested on Drupal 7 yet), called File Taxonomy Server Lite (fts_lite for short), which provides access to Drupal files using taxonomies through WebDAV. The idea for the module comes from File Server (http://drupal.org/project/fileserver), but the code has been completely re-written and the functionality is somewhat improved.

The module only depends on the DAV module (http://drupal.org/project/dav) and Drupal's Core Upload. It does *not* depend in any way on File Framework (as File Server and File Relations do) – that's why it is "lite". To my knowledge, this would be the only published module to implement WebDAV access to files that works with the core.

For the module to work, nodes with associated file attachments must be tagged by terms of some vocabularies. Then, by exposing such vocabularies through WebDAV, the user gains access to such files.

The module promotes (some would say "enforce") the policy "one node - one file". To use the module, the user must designate a content type for files and upload a single file to each node of that type (in the current implementation, if a node contains multiple attachments, only the first will be visible through WebDAV).

The module works as follows: the user chooses one or more vocabularies to be exposed through WebDAV. After that, the user can login using her/his WebDAV client and will be presented a "file system" view of the selected vocabularies. Vocabularies are mapped onto top directories, while terms are subdirectories containing other term-directories and files (which are the files associated to nodes tagged by the given term).

The user has the ability to upload/move/copy/delete/download files and folders. The semantics of such operations, although intuitive, is not exactly the same as for a real file system, but it closely reflects the behaviour of Drupal's interface for manipulating taxonomies. Some examples:

1) moving a file to a different subdirectory just re-tags the associated node;
2) copying a file to a different subdirectory adds a term to the associated node;
4) moving a subdirectory corresponds to moving a term (moving to different vocabularies and promoting a term to a vocabulary are also allowed);
etc…

Deletion of files corresponds to untagging files and deletion of folders corresponds to deletion of terms and/or vocabularies. Nodes and attached files *cannot* be deleted through WebDAV (although, in the future, an option to allow that may be implemented). In this sense, the module is safe, because it is not possible to inadvertently delete a node or a file. The module also supports node revisions (if enabled for the designated content type).

The module already supports any kind of vocabulary, including free tagging vocabularies and multiple choice vocabularies.

One of the design goals of my project is information integrity (efficiency has a lower priority): no data should be inadvertently lost by operations through WebDAV. I have already mentioned that nodes/files cannot be deleted. Also, term synonyms and relations are preserved (if possible). Note that some operations are far from being trivial: consider, for example, moving a term containing a bunch of sub-terms with multiple parents and relations to a different vocabulary. Some information loss in this case may be inevitable (some parents and some relations may be lost), because the "file system" view is a tree whereas the taxonomy is a dag, but great care has been taken to minimize such loss (a user preference to forbid moving terms across vocabularies is planned, however).

To achieve the best consistency with the web interface, all operations make use of drupal_execute() rather than "lower level" methods (e.g., directly calling node_save() or directly accessing the database), to ensure that all validations are performed.

Another design goal is security: only users who have been granted permissions to access the files are able to so.

To summarize, the module has *complete* functionality to manage files through WebDAV in a safe way and it is the only module that does that. By depending only on Core Upload, I believe that it may have more widespread use than File Server or File Relations, which require the complex File Framework. If complemented with tac_lite (for example), it may easily provide "automatic" access control for files (e.g., upload a file to have it automagically accessible only by a given role or user). Its main limitations are the limitations of the DAV module (e.g., some clients do not display filenames but id's, …)

Features that may be added in the future include:

0) more user preferences (e.g., choose the semantics for file deletion);
1) support for CCK File Upload;
2) support for multiple attachments to each node;
3) support for WebDAV module (already partially implemented), as an alternative.
4) support for OG vocabularies.

My contact email is

nvitacolonna@gmail.com

Sincerely,
druido

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

lifepillar’s picture

Component: Miscellaneous » Code
Status: Postponed (maintainer needs more info) » Needs review
FileSize
21.55 KB
apaderno’s picture

Component: Code » Miscellaneous
Issue tags: +Module review
lifepillar’s picture

If you test this with PHP 5.3, please consider taking a look at http://drupal.org/node/653774

apaderno’s picture

Status: Needs review » Needs work
  1. ; Information added by drupal.org packaging script on 2008-09-08
    version = "6.x-1.0-alpha1"
    core = "6.x"
    project = "fts_lite"
    datestamp = "1220913311"
    

    Those lines should be removed because they are already added by the packaging script.

  2. The file LICENSE.txt needs to be removed; Drupal.org CVS doesn't allow to commit that file.
  3. /**
    * Implementation of hook_enable().
    */
    function fts_lite_enable() {
      drupal_set_message(t('File Taxonomy Server Lite (FTS_Lite) was successfully installed. Please review the available <a href="@settings">configuration settings</a>.', array('@settings' => url(FTS_LITE_ADMIN_PATH))));
    }
    

    That message would be displayed every time the module is enable, not only when the module is installed.

  4. /**
     * Implementation of hook_update_N(). Upgrades settings from 4.7.x due to module rename.
     */
    function fts_lite_update_6100() {
      $old_vocabs = variable_get('file_server_vocabularies');
      if ($old_vocabs) {
        variable_set('fts_lite_vocabularies', $old_vocabs);
      }
      $old_og_vocabs = variable_get('file_server_og_vocab');
      if ($old_og_vocabs) {
        variable_set('fts_lite_og_vocab', $old_og_vocabs);
      }
      return array();
    }
    

    Module rename? If the module has been renamed, which one was the previous name?

  5.   $route = webdav_parse_path($path);
      $key = array_pop($route);
      if (!is_numeric($key)) { // path to a file node
       webdav_session_set_status(WEBDAV_STATUS_NO_CONTENT);
    

    The module calls functions defined from the other module, but the module is not declaring its dependency from the other module.

lifepillar’s picture

FileSize
16.6 KB

1. Fixed.
2. Fixed.
3. Fixed.
4. Fixed (a leftover from the File Server code this project was started with).
5. Those functions are not currently used (as I've said, support for the WebDAV module is only partially implemented). The only dependency of the module in its current form is the DAV module.

New feature: the user can now choose the file node type in the configuration.

lifepillar’s picture

Status: Needs work » Needs review
apaderno’s picture

Status: Needs review » Needs work
  1. module_load_include('inc', 'node', 'node.pages');
    module_load_include('inc', 'taxonomy', 'taxonomy.admin');
    

    If you are going to load the files in any cases, then it is better to merge the files in the module file.

  2. // TODO: check strings to be surrounded by t()
    // TODO: check difference between == and === (!= and !==)
    

    The presence of this comments makes me think the code has not been completely developed; I would expect that a module proposed for a CVS application already uses t() in the proper cases, and it uses the correct comparison operator.

  3. // Loader for vocabularies
    function fts_lite_vocabulary_load($vid) {
      return $vid;
    }
    

    If the loader function is simply returning the parameter passed to it, then you can simply use the generic wildcard % in the menu callback; you use a named wildcard if the loader effectively loads data from the database.

  4.   $options = array_map(create_function('$vocab', 'return $vocab->name;'), taxonomy_get_vocabularies());
    

    For such simple case there is no reason to use create_function.

  5. See the Drupal coding standards to understand how a module code should be written. In particular, see how the code should be formatted.
lifepillar’s picture

Status: Needs work » Needs review
FileSize
16.63 KB

1. If you are going to load the files in any cases, then it is better to merge the files in the module file.

What do you mean?

2. Fixed (revised t() and comparisons).
3. Fixed.
4. The way it is done is not wrong or not conforming to coding standards. Can you please suggest a better way?
5. Done. Revised with Coder and code-style.pl.

apaderno’s picture

Status: Needs review » Needs work

The various TODO in the code make me think the code has not been completed, which is one of the requirements listed in Apply for contributions CVS access.

apaderno’s picture

Status: Needs work » Closed (won't fix)

There have not been replies in the last week. I am marking this application as won't fix.