Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

Sub-Community Management

Reindex content for new permissions to take effect

After moving or changing an existing Community hierarchy, it is important to reindex your content.  Moving a Community under a new parent may result in the inheritance of new/different permissions from that new parent Community.  These new permissions will not take effect until you reindex your content.  Keep in mind, you may not need to reindex all content, but may be able to simply reindex the content under the new parent Community.

./dspace index-discovery -i [new-parent-uuid] 

DSpace provides an administrative tool‚ 'CommunityFiliator'‚ for managing community sub-structure.  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