This is a bug in the source code and its documentation that has no effect in practice, other than misleading those who may read the code documentation.

In the method Table_CollectionTree::findPairsForSelectForm() :

/**
     * Return the collection tree hierarchy as a one-dimensional array.
     *
     * @param array $options (optional) Set of parameters for searching/
     * filtering results.
     * @param string $padding The string representation of the collection depth.
     * @return array
     */
    public function findPairsForSelectForm(array $options = array(), $padding = '-')
    {
        if (isset($params['padding'])) {
            $padding = $params['padding'];
        } else {
            $padding = '-';
        }
        $options = array(); /////////////////////////////////  <<<<<<<<<< THIS
     
        //.....

The first parameter, $options, is completely unused, as it's overwritten with an empty array before it's ever used. No matter what you pass to the method in this parameter, it will have no effect whatsoever.

More importantly, the documentation for the parameter doesn't say so:

/*
     * @param array $options (optional) Set of parameters for searching/
     * filtering results.
...
*/

Whatever that is supposed to mean, it's not true, as the argument has no effect.

"Nested" is ambiguous. Since the plugin is already in use, this will require a specialized upgrade path for early adopters:

1. Delete the old Nested plugin directory without uninstalling or disabling the plugin;
2. Save the new NestedCollections plugin directory;
3. Install the "Nested Collections" plugin.

During installation (not upgrade), if a plugin names "Nested" exists in the plugins table:

1. Delete the "Nested" plugin from the plugins table
2. Perform any alterations to the plugin tables.

@sheilabrennan, @leeannghajar

I suggest that you first create at least ten collections named in a series, e.g. one, two, three, four, ... When adding/editing the collections, under "Parent Collection", assign a parent collection to each of these collections. Afterwards, check that the hierarchy tree represents these changes on the collection's show page and the "Collection Tree" page.

If you encounter anomalies, try to remember the steps you took before seeing them.

This one too, @zerocrates-- and there will probably be others.

Maybe @jimsafley can do this one?

On this discussion, Jeremy made the following suggestion:

Looks like this would be a great opportunity to add a filter to the collections select menu on the Item form. (LIkely just have a filter for _select_from_table). Having a list of nested collections separate from the form input where you actually choose the collection is less than ideal.

This will be a two step process. First, in Omeka core, filter the select options returned from findPairsForSelectForm(), using something like this (note the apply_filters()):

<?php
function _select_from_table($tableClass, $props = array(), $value = null, $label = null, $searchParams = array())
    $options = get_db()->getTable($tableClass)->findPairsForSelectForm($searchParams);
    $options = apply_filters(Inflector::underscore($tableClass) . '_select_options', $options);
    return select($props, $options, $value, $label);
}

Second, in the CollectionTree plugin, add a collections_select_options filter callback that returns the collection hierarchy represented as a one-dimensional array where individual characters (probably spaces) represent the collection depth. For example:

<?php
array(
    1 => "Collection One",
    3 => "    Collection Three",
    4 => "        Collection Four",
    6 => "        Collection Six",
    2 => "Collection Two",
    5 => "    Collection Five",
)

This way the collection select form on the item add/edit page will be easier to use.

Reported in forums http://omeka.org/forums/topic/collection-tree-permissions-related-error

Need to add the ability to do multi level nesting.

I think sorting would be a nice feature to have. I would like to be able to add sort alphabetically.

On the advanced search form, the field "Expand to subcollections" has a label 'for="public"', but the 'public' field ID is already used by the search-by-public field, and the checkbox of the 'Expand to subcollections' field has the ID 'subcollections'.

Hence, on line 332 of /CollectionTree/CollectionTreePlugin.php the label should be changed to 'for-"subcollections"'.

I believe there is an issue with the padding for collections list: in models/Table/CollectionTree.php it's supposed to be passable as a parameter, but then it's hardcoded ignoring the parameter.

I suggest to remove the following code from findPairsForSelectForm function:

        if (isset($params['padding'])) {
            $padding = $params['padding'];
        } else {
            $padding = '-';
        }

Install tag v0.1, insert test data, and test the upgrade from v0.1 (Nested) to the current version (NestedCollections). Due to the nature of the the upgrade, the upgrade code is located in the install hook.

On a 3.1 installation, when the plugin is enabled, collections appear to lose their names when viewed in any dropdown of collections:

(The last image is the dropdown in the Timeline plugin)

The only thing that I can see differentiating the "Public Domain Items" collection from the others is that none of my collections have any metadata filled out, except that one. It has Description and Creator values.

I'm wondering if the plugin can insert the collection tree bullet list higher up on the collection view page. I would want it with the metadata, at the top of the page, before seeing the contained items, rather than down at the end of the page.

Maybe it could be styled more like the metadata too, with "Collection Tree" in bold and to the left, and the bullet list to the right?

http://dev.omeka.org/amayer/amayer-c/omeka/collections/show/1

One idea is to load collection and hierarchy data before dispatch and use that to build collection hierarchy. Only load collection data on actions that need hierarchy data.

See https://github.com/omeka/plugin-NestedCollections/tree/experimental

Parent-child relationship on collections/show, similar to Seasons in that bullets are at same indent.

&
• styling issues, child collection displays in slightly larger font-size than parent.

@sheilabrennan, @leeannghajar

Before installing the plugin, make sure you have a few collections already in your repository. After installing the plugin you should see these collection names, all ordered at the root level, on the "Collection Tree" page.

Parent-child relationship not obvious, both collections listed with bullets w/o indentation on the collections/show page. Child should be indented.

Working from this forum post -
Currently each relationship has to be created manually from the child collection. Would it be possible either to create a bulk edit for collections, or enable parents to choose child collections?

The Griddy theme seems to style

s without a left margin, so the indentation of the tree in Griddy doesn't show up.

On collections/show--div items are not separated so that the collection parent and child names are listed next to the list of collection items.

Need to add the ability to do multi level nesting.