Date: Fri, 29 Mar 2024 11:16:17 -0400 (EDT) Message-ID: <1457260572.245.1711725377407@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_244_795138073.1711725377407" ------=_Part_244_795138073.1711725377407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
DSpace provides an administrative tool=E2=80=9A 'CommunityFiliator'=E2= =80=9A 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 hie= rarchy. It has two operations, either establishing a community to sub-commu= nity 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=E2=80=9A meani= ng it has at least one sub-community, or a 'child' community=E2=80=9A meani= ng 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 DSpa= ce user-interface, since there is no parent community 'above' them. The fir= st operation=E2=80=9A establishing a parent/child relationship - can take p= lace between any community and an orphan. The second operation - removing a= parent/child relationship=E2=80=9A will make the child an orphan.
Command used: |
|
Java class: |
org.dspace.administer.CommunityFiliator= em> |
Arguments short and (long) forms: |
Description |
|
Set a parent/child relationship |
| Remove a parent/child relationship |
| Child community (Handle or database ID) = td> |
| Parent community (Handle or database ID = td> |
| Online help. |
Set a parent/child relationship, issue the following at= the CLI:
[dspace= ]/bin/dspace community-filiator --set --parent=3DparentID --child=3DchildID=
(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 communit= y identified by the '-p' parameter becomes the parent of the community iden= tified 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=3DparentID --child=3Dchil= dID
(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 commu= nity 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 par= ent.
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 i= tself children (sub-communities), or collections, they will all move with i= t to its new 'location' in the community tree.