Old Release

This documentation relates to an old version of DSpace, version 5.x. Looking for another version? See all documentation.

Support for DSpace 5 ended on January 1, 2023.  See Support for DSpace 5 and 6 is ending in 2023

Sub-Community Management

DSpace provides an administrative tool‚ 'CommunityFiliator'‚ for managing community sub-structure. Normally this structure seldom changes, but prior to the 1.2 release sub-communities were not supported, so this tool could be used to place existing pre-1.2 communities into a hierarchy. It has two operations, either establishing a community to sub-community relationship, or dis-establishing an existing relationship.

The familiar parent/child metaphor can be used to explain how it works. Every community in DSpace can be either a 'parent' community‚ meaning it has at least one sub-community, or a 'child' community‚ meaning it is a sub-community of another community, or both or neither. In these terms, an 'orphan' is a community that lacks a parent (although it can be a parent); 'orphans' are referred to as 'top-level' communities in the DSpace user-interface, since there is no parent community 'above' them. The first operation‚ establishing a parent/child relationship - can take place between any community and an orphan. The second operation - removing a parent/child relationship‚ will make the child an orphan.

Command used:

[dspace]/bin/dspace community-filiator

Java class:


Arguments short and (long) forms:


-s or --set

Set a parent/child relationship

-r or --remove

Remove a parent/child relationship

-c or --child

Child community (Handle or database ID)

-p or --parent

Parent community (Handle or database ID

-h or --help

Online help.

Set a parent/child relationship, issue the following at the CLI:

[dspace]/bin/dspace community-filiator --set --parent=parentID --child=childID

(or using the short form)

[dspace]/bin/dspace community-filiator -s -p parentID -c childID

where '-s' or '-set' means establish a relationship whereby the community identified by the '-p' parameter becomes the parent of the community identified by the '-c' parameter. Both the 'parentID' and 'childID' values may be handles or database IDs.

The reverse operation looks like this:

[dspace]/bin/dspace community-filiator --remove --parent=parentID --child=childID

(or using the short form)

[dspace]/bin/dspace community-filiator -r -p parentID -c childID

where '-r' or '-remove' means dis-establish the current relationship in which the community identified by 'parentID' is the parent of the community identified by 'childID'. The outcome will be that the 'childID' community will become an orphan, i.e. a top-level community.

If the required constraints of operation are violated, an error message will appear explaining the problem, and no change will be made. An example in a removal operation, where the stated child community does not have the stated parent community as its parent: "Error, child community not a child of parent community".

It is possible to effect arbitrary changes to the community hierarchy by chaining the basic operations together. For example, to move a child community from one parent to another, simply perform a 'remove' from its current parent (which will leave it an orphan), followed by a 'set' to its new parent.

It is important to understand that when any operation is performed, all the sub-structure of the child community follows it. Thus, if a child has itself children (sub-communities), or collections, they will all move with it to its new 'location' in the community tree.

  • No labels


  1. Is it necessary to re-index after running community-filiator? If so, is index-discovery -o sufficient?

    1. I don't think so.  The Discovery core doesn't contain community hierarchy information, so that must be coming from the database.  But you may need to clear the Cocoon cache (if using XMLUI) before the breadcrumb trails reflect the new hierarchy.