Introducing Organizational Units

1 Requirements

Up to now, organizational structures can only be mapped in ILIAS by creating a category for every single organizational unit, so permissions can be restricted effectively to the persons in charge (by creating local roles).
With big, internationally working companies e.g., this way the repository structure and also the RBAC become very large and, thus, usability and performance are affected.
 
This effort may be inevitable where each organizational unit has its own educational program, its own content a.s.o.
However, in many cases this is not the case but (at least partially) the same educational program and content is used throughout the entire organization.
Despite of that, we currently need separate containers (category, course) to ensure that only trainers or superiors in charge can, e.g.:

• View the learning data of "their" employees,
• Assign (or detach) those employees to courses,
• Be notified about events regarding those employees,

1.1 General Ideas

Organizational units represent the structure of an organization, like departments and subdepartments.
However, unlike the Repository structure, they only structure subsets of user accounts but not those of Repository objects.
Thus, it is possible to run only one course on the entire platform but provide specific tracking facilities for each organizational unit, so tracking surveyors can only view the data of their employees.
 
Use Cases are:

• Maintenance of organizational units in the ILIAS administration (separate dialogue)
  • Import of organizational units from Excel via .xml data import
    • Import of titles, IDs and additional orgunit properties
    • Excel-based tool available: Macro checks and converts data to .xml
  • Expendable tree view showing all org units (JsTree is to be used throughout the feature!)
  • Graphical emphasis of users responsible for an orgunit (s. also topic "orgunit roles" below)
  • Display of user assigned to orgunits, incl. properties:
    User ID, Assigned on, Assigned by, Assigned as role, Responsible?, Other assigned units
  • Display of properties of single orgunits:
    Short title, Long description, ID, Organization Type, Created on, Created by, Number of assigned users, Responsible user for the unit
  • Options to edit or delete the orgunit
  • Manual creation of organizational (sub-)units
    • Creation screen incl. titles, IDs and additional orgunit properties (like "Type" with categories "Office" / "Shop" / "Field service")
    • Note: Those orgunits do not have an ImportId but one assigned by ILIAS

• Assignment of permissions in organizational units via orgunit roles:
  
  We consider the introduction of a special role system in organizational units necessary:
  The RBAC system used in the repository does only affect objects - however, orgunits aren't objects in the meaning of repository objects!
  They are a separate structure with completely diferent kinds of permissions.
  Further differences to RBAC roles:
  • No permission inheritance
  • No local roles in individual tree nodes but only one set of ("global") roles
  • Within one orgunit, a user can only have one orgunit role

• Creation and maintenance of orgunit roles:
  • Display of orgunit roles (in sub-tab of the "Organizational Units" dialogue)
    • Differences to RBAC roles:
    • The handling of orgunit roles could be facilitated if their look&feel was adjusted to the one of RBAC roles
    • Analogous to RBAC, there should already some default roles be provided when installing ILIAS
  • Options to edit or delete those roles
  • Creation of those roles, incl. title and possible permissions:
    • Responsibility for orgunit
    • Access to (aggregated) reporting of orgunit
    • Access to person-related reports
    • Appearance in reporting
    • Manual course assignment for orgunit
    • Decentral user administration (for both, s. related topic "Bulk Assignmen" below")

• Import of user-orgunit relations in the ILIAS administration (dialogue "User Accounts"):
  The existing .xml data import for user accounts can be extended with columns containing orgunit relations, i.e.:
  • To what organizational unit(s) is a user assigned?
  • What permissions does an assigned user have in the organizational unit (by assigning orgunit roles)?

• Maintenance of user-orgunit relations in the ILIAS administration (in single user accounts, tab "Organizational Units")
  • Expendable tree view showing all org units and display of properties of single orgunits (s. above)
  • Option to assign user, incl. selection of orgunit

1.2 Patch Version Databay

Patch Version Databay

1.2.1 Mock-Up

Mock-up

OrgUnit Import
OrgUnit Editing
OrgUnit Roles
OrgUnit User Assignment

1.2.2 Data Structure (current patch version, 14 Jan 2013)

Data structure of current patch version, 14 Jan 2013

• The organizational units are organized in a hierarchical tree (org_unit_tree + org_unit_data)
• org_unit_data
  • ou_id
    • system id
  • ou_title
  • ou_subtitle
    • long description of ou
  • ou_import_id
    • id of orgunit, that was used with xml-import
  • ou_create_date
    • date/time of creation
  • ou_update_date
    • date/time of last update
  • ou_owner_id
    • user id of user who created/imported the orgunit
    • if owner "1", ou can not be manipulated (edit, delete, move) with gui
      • appropriate message in gui is displayed
      • used for automated ou creation/management (e.g by cron job)
  • ou_num_users
    • redundant calculation of all users of the subtree
  • ou_num_reported_users
    • only calcualte users that get reported
  • ou_type
    • type of ou from selected list
    • could be used to select ou's of same type (e.g. in reporting) if ou's on different levels of tree
• OU assignments and org roles are organized in org_unit_assignments + ou_role_templates
• org_unit_assignments
  • oa_ou_id
  • oa_usr_id
  • oa_reporting_access
    • read access to the reporting of this department: see put org units into main tree concept below
  • oa_create_date
    • date/time of assignment creation
  • oa_update_date
    • date/time of assignment update
  • oa_is_responsible
    • different user icon in tree gui
    • used e.g. for compliance processes
    • responsible persons gets notification emails on employess in the compliance process
  • oa_is_reported
    • user will be tracked in reporting
  • oa_reporting_recursive
    • controls whether reporting is limited to directly assigned employees of the org unit, or whether the whole subtree is displayed
    • currently this only affecs user related data, not aggregated data. Aggregated data is always displayed for all users of the subtree and grouped by the next level of the tree.
    • if we implement the the "main tree apporoach" this setting could be permissions (see only on level / see subtree)
  • oa_or_fi
    • org role ID used with assignment (obligatory)
  • oa_crs_assign
    • allows to assign courses to users of this org unit (plugin)
  • oa_usrfou
    • access to the decentralized user management of this org unit (plugin)
    • allows to manage users of the org unit
    • add completely new users
    • currently it is not possible to assign existing users of other org units
  • oa_owner_id
    • user id who created/imported assignment

• ou_role_templates
  • id
  • name
  • reporting_access
  • reporting_recursive
  • reporting_is_reported
  • usrfou
  • crsassign
  • reporting_is_resp

custom.ini documentation (of current patch)

Several configuration options can be used to adjust the feature/s.
Configuration options can be changed by editing files on server (custom.ini.php, ou_types.csv etc.)
 
Example custom.ini.php
 
[ORGUNIT]
 
orgrole_delete_template_cmd_enabled = 1                    ; <1|0> controls the orgrole template deletion feature
outree_import_xml_root_unit_parent = "ilias"
 
 
[REPORTING]
 
cron_fetch_mandatory_crs_membership_info            = "0"            ; <0/1> - fetch mandatory crs membership info within the reporting storage builder or not (depends on patch feature!!)
cron_fetch_autoassigned_crs_membership_info            = "0"            ; <0/1> - fetch autoassigned crs membership info within the reporting storage builder or not (depends on patch feature!!)
cron_fetch_compliance_certificate_info                = "0"            ; <0/1> - fetch compliance certificate info within the reporting storage builder or not (depends on patch feature!!)
debug_enabled                                        = "0"            ; <0/1> - enables a debug mode, that provides additional info (cache files only)
udf_name_for_detailed_field_usr_position            = ""            ; <udf_name> or EMPTY - udf name of field that is to be used as source for detailed_field_usr_position, falls back to usr profile field department
cache_lifetime                                        = "0"            ; <seconds> - for the lifetime of query cache files (EXPERIMENTAL!!)
 
course_selection_root_ref_id                        = "1"            ; <container_ref_id> - only courses from the subtree of this repo container are reported
map_lp_failed_to_in_progress                        = "1"            ; <0/1> - map the lp status "failed" to "in_progress"
 
custom_totals_entity_lang_variable                    = ""            ; <lang_identifier> - left empty for automatic label or set to e.g. "ccmt_all_employees" or any other custom (new) lang var
 
short_info_box_enabled                                = "0"            ; <1/0> - controls the display of short info box above reporting tables
summary_table_enabled                                = "1"            ; <1/0> - controls the display of the summary table for aggregated reports
 
detailed_report_printview_commands                    = "0"            ; <1/0> - controls the availability of printview commands for detailed reports
 
toolbar_switch_numbers_mode                            = "1"            ; <1/0> - controls the availability of selection for numbers mode (absolute/relative numbers)
toolbar_filter_course                                = "1"            ; <1/0> - controls the availability of course filter
toolbar_filter_crsparent                            = "0"            ; <1/0> - controls the availability of course parent category filter
toolbar_filter_crstype                                = "0"            ; <1/0> - controls the availability of course type (OPTIONAL/MANDATORY MEMBERSHIP - CUSTOM COURSE PROPERTY !!)
toolbar_filter_memtype                                = "0"            ; <1/0> - controls the availability of membership type (AUTO/MANUAL MEMBERSHIP - CUSTOM COURSE PROPERTY !!)
toolbar_filter_period                                = "0"            ; <1/0> - controls the availability of period filter
 
viewby_mode_course                                    = "1"            ; <1/0> - controls the availability of viewby mode course
viewby_mode_course_type                                = "0"            ; <1/0> - controls the availability of viewby mode course type (OPTIONAL/MANDATORY/AUTO/MANUAL MEMBERSHIP - CUSTOM COURSE PROPERTY !!)
viewby_mode_course_parent                            = "0"            ; <1/0> - controls the availability of viewby mode course parent category
viewby_mode_orgunit                                    = "1"            ; <1/0> - controls the availability of viewby mode orgunits
viewby_mode_user                                    = "1"            ; <1/0> - controls the availability of viewby mode user
 
detailed_field_user                                    = "1"            ; <1/0> - controls the display of column "user" for detailed reports
detailed_field_course                                = "1"            ; <1/0> - controls the display of column "course" for detailed reports
detailed_field_lp_status                            = "1"            ; <1/0> - controls the display of column "lp_status" for detailed reports
detailed_field_lp_status_date                        = "0"            ; <1/0> - controls the display of column "lp_status date" for detailed reports (NOT IMPLEMENTED YET !!)
detailed_field_usr_position                            = "0"            ; <1/0> - controls the display of column "usr_position" for detailed reports (UDF USER PROPERTY !!)
detailed_field_last_access                            = "0"            ; <1/0> - controls the display of column "last_access" for detailed reports
detailed_field_course_type                            = "0"            ; <1/0> - controls the display of column "course_type" for detailed reports (OPTIONAL/MANDATORY MEMBERSHIP - CUSTOM COURSE PROPERTY !!)
detailed_field_session_date                            = "0"            ; <1/0> - controls the display of column "session_date" for detailed reports (date of single session within course)
detailed_field_session_num_days                        = "0"            ; <1/0> - controls the display of column "session_num_days" for detailed reports (num days of single session within course)
detailed_field_cmplcert_achievement_date            = "0"            ; <1/0> - controls the display of column "cmplcert_achievement_date" for detailed reports
detailed_field_cmplcert_expiration_date                = "0"            ; <1/0> - controls the display of column "cmplcert_expiration_date" for detailed reports
 
aggregated_field_aggregation_entity                    = "1"            ; <1/0> - controls the display of column "aggregation_entity" for aggregated reports
aggregated_field_num_orgunit_assignments            = "1"            ; <1/0> - controls the display of column "num_orgunit_assignments" for aggregated reports
aggregated_field_num_course_assignments                = "1"            ; <1/0> - controls the display of column "num_course_assignments" for aggregated reports
aggregated_field_num_lp_completed                    = "1"            ; <1/0> - controls the display of column "num_lp_completed" for aggregated reports
aggregated_field_num_lp_failed                        = "0"            ; <1/0> - controls the display of column "num_lp_failed" for aggregated reports
aggregated_field_num_lp_in_progress                    = "1"            ; <1/0> - controls the display of column "num_lp_in_progress" for aggregated reports
aggregated_field_num_lp_not_attempted                = "1"            ; <1/0> - controls the display of column "num_lp_not_attempted" for aggregated reports
aggregated_field_lp_ratio                            = "1"            ; <1/0> - controls the display of column "lp_ratio" for aggregated reports
aggregated_field_num_cmplcert_certificates            = "0"            ; <1/0> - controls the display of column "num_cmplcert_certificates" for aggregated reports
 
 
Example ou_types.csv

"department","all departments"
"team","all teams"
"not specified","org unit type is not specified"

1.3 Related Topics

This article is only a part of an entire complex of features.
Immediately related topics are:

• Bulk Course Assignment by Org Units
• Compliance processes by Org Units
• Reporting by Organizational Units
• User Administration by Org Units
• Seminar Management
• Training Budget
• Course Booking/Cancellation by Superiors

2 Status

• Scheduled for Release: Release 4.4
• Funding: SSI Schäfer
• Development: Feature is to be developed by sr.solutions

3 Additional Information

• If you want to know more about this feature, its implementation or funding, please contact: Martin Studer sr.solutions

4 Discussion

Alex Killing, 25 Feb 2013: The massive number of configuration options in the ini files is very uncommon for ILIAS components. I guess most of this should go to the ILIAS administration and be available through the user interface.

Alex Killing, 11 Apr 2013: In my opinion the arguments above for not using exisiting concepts in ILIAS, especially repository objects and the RBAC, are not very strong.

• Point 1 "The RBAC system used in the repository does only affect objects, however orgunits aren't objects": There is no reason why OrgUnits are not represented by ILIAS objects. We could easily introduce an OrgUnitFolder in under the administration node of the repository and make OrgUnits repository objects that contain other OrgUnits as subelements. This would allow to reuse existing code for moving/copying and other features, too.
• Point 2 "They are a separate structure with completely different kinds of permissions": As outlined above a separate structure can be represented as subtree under an administration node without any problems. As each repository object in ILIAS also defines its own permissions, "different kinds of permissions" is no reason not to use the RBAC. Moreover the current impementation of the OrgUnit patch makes it quite hard to introduce new permissions. The RBAC allows this with a few lines of code in the DB update script.
• Point 3 "No permission inheritance": The current OrgUnit patch introduces a flag "Rekursivität" that may serve similar needs. The problem of this flag is that it is unclear on which permission it acts. And somtimes there seems to be the need to finetune more granular which OrgUnits of a tree can. We should test some scenarios against an RBAC based approach. This would allow to reuse a lot of existing code.
• Point 4 "No local roles in individual nodes": The "local" character in the current OrgUnit patch comes through the fact that users are not only assigned to roles, but to roles in org units. This is very similar to introducing local roles and to assign the users here. Each OrgUnit could come with an "Employee" and a "Superior" local role, like courses come with a "Tutor" and "Member" role. These roles could also be initialised by role templates. Having local roles would also allow to finetune permissions differently in different OrgUnits.
• Point 5 "Within one orgunit, a user can only have one orgunit role": Yes, RBAC currently allows to assign users to multiple roles in every tree node. Would this be really a problem for OrgUnits? If so, we could discuss to modify the RBAC in a way, that certain object types (e.g. OrgUnits) do not allow to assign users to multiple roles. I currently see no reason why it should not be possible to extend RBAC in this way.

Alex Killing, 2 May 2013: I added the topic to the advisory council meeting. I think some paper-based scenario testing should be done before making a decision on the implementation. There is one new idea in the PDF, the "Additional Permissions" tab. I am not sure how this is supposed to work, basically how the permission would be added? If the plugin uses the permission, the plugin should add the permission, too. However this could be done via a slot interface either offered by the OrgUnit or the RBAC component. But I doubt that the RBAC is currenltly ready for such a flexibility - adding such permissions is easily done, but removing them completely not that easy.
 
For a first use in ILIAS it is important that the organisational structure offers some functionality already. We do not want it only for administrating such a structure without any value added (without the use of plugins). As far as I see it, controling the access to learning progress of employees is quite a standard requirement that is asked for many times already. So my suggestion is that the core comes already with two permissions "Access to Individual Learning Progress" and "Access to Aggregated Learning Progress" and a simple reporting feature based on learning progress screens we already have and an OrgUnit plugin slot for custom screens that can be used at least for custom reporting needs.

JF 13 May 2013: Today we discussed the Seminar Management features suggested for ILIAS 4.4 and the organizational units proposed on this page. We support the introduction of organizational units in ILIAS and see it as a precondition for features listed on the Seminar Management page. We would like to schedule a basic implementation of the organizational units for 4.4 and to continue to discuss all other features after we gained more experience in a number of customer projects with "patched" solutions.
 
We prefer an implementation of the org-units that is based on existing concepts (RBAC, ilObject, ...):

• Organisational units are organised in an repository object subtree under the administration repository node.
• OrgUnits are derived from common Object classes (ilObject, ...)
• The (optional) creation of default local roles for employees and superiors is supported. (using global role templates)
• Local user administration is supported (similar to categories).
• Permission to access learning progress of the OrgUnit.

Alex, 4 June 2013:

• Introducing new events should be no problem.
• I think we should not use the term "recursive permission". We introduce permissions, we do not need a technical concept for recursiveness. We can discuss, wether we need e.g. a first permission "Access Learning Progress of Unit" and a second permission "Access Learning Progress of Unit incl. Subunits".
• Since the OrgUnit objects are repository objects they come with the import_id attribute automatically. The OrgUnit implementation can decide to present this information or not.
• A basic XML import and export should be possible.

JF 10 June 2013: We agree with Alex remarks. An additional CSV export can be added.
 
We also shortly discussed the requirement that user/role assignments that have been added by external systems (import/LDAP) may be locked for the user interface. We did not finish this discussion yet, currently this feature would be postponed.

5 Implementation

ILIAS 4.4 contains the discussed points of the JF held on 13 May 2013:
 
We prefer an implementation of the org-units that is based on existing concepts (RBAC, ilObject, ...):

• Organisational units are organised in an repository object subtree under the administration repository node.
• OrgUnits are derived from common Object classes (ilObject, ...)
• The (optional) creation of default local roles for employees and superiors is supported. (using global role templates)
• Local user administration is supported (similar to categories).
• Permission to access learning progress of the OrgUnit.

• Editable import_id
• XML-import and -export of Organizational Units incl. the possiblity of role assignments
• Permission "Access Learning Progress of Unit incl. Subunits"

5.1 Configuring Organizational Units

5.2 Access to Learning Progress by Superiors

5.3 Role based access control

5.4 Local User Administration - e.g. for each company

5.5 Export and Import Functions

5.6 The possibility of using the Organisational Units in a plugin - e.g. a reporting plugin

5.6.1 Example Code for using in Plugins

ilObjOrgUnitTree::_getInstance()->getOrgusWhereUserHasPermissionForOperation($operation_id)
 
OR
 
ilObjOrgUnitTree::_getInstance()->getEmployeesUnderUser($user_id, $recursive)

 
OR
 
ilObjOrgUnitTree::_getInstance()->getSuperiorsOfUser($user_id, $recursive)
 
...
 

6 Test Scenario and Test Cases

6.1 Setup Test Scenario

1. Create a new global role which allows users to view/read OrgUnits, e.g. "View and read OrgUnits".
2. Assign this role to users, which should be able to see OrgUnits. These users typically are the Superiors.
3. Open "Administration > General settings > Permissions" and check the permissions "Visible", "Read" and "Local policy" for the role created step 1.
4. Open "Administration > Organisational Units > Permissions" and check "Local policy", "Visible" and "Read".
5. Activate "Learning progress" under "Administration > Statistics and Learning Progress". Also uncheck the "Anonymized" checkbox.

You can also create this structure with the following XML-Export and import the file by clicking "Simple XML Import" on the root node of your OrgUnits.

6.2 Test Cases

6.2.1 User without global role "View and read OrgUnits" can't access Organisational Units

Test-Steps

1. Login with a user that does not have the role "View and read OrgUnits". You should not be able to view the "Administration" or "Administration > Organisational Unit"

6.2.2 Only users with local role "Superior" are able to see the learning progress of their employees

Setup / Preconditions

1. Add a user which has the global role "View and read OrgUnits" as Superior under "Company 1 > Division 1 > Team 1"
2. Add a second user as Employee in the same OrgUnit

1. Login as the user assigned as Superior under "Team 1".
   1. Navigate to the OrgUnit "Team 1". You should see the "staff" tab and be able to view the learning progress of the employee.
2. Login as another User which has the global role "View and read OrgUnits".
   1. Navigate to the same Orgunit "Team 1". You shouldn't see the "staff" tab at all.

6.2.3 Show learning progress recursivly with new local role

Setup / Preconditions

1. Add one or more (new) users as Employees under "Company 1 > Division 1 > Team 2".
2. Select the "Division 1" OrgUnit and create a new local role under "Permissions". Check permission "View Learning Progress recursivly".
3. Add the role to a Superior User under "Staff > Additional Roles Division 1"

1. Login as the superior user which has the newly created local role.
   1. Navigate to the OrgUnit "Division 1", click on "Staff" and then "Employees Division 1 recursivly". You should see all Employees from Team 1 and Team 2 and be able to view their Learning Progress.
2. Login as another superior who doesn't have the local role.
   1. Navigate to the OrgUnit "Division 1". You shouldn't see the "staff" tab at all.

6.2.4 Add a user which can administrate local users under an OrgUnit

Setup / Preconditions

1. Create a new local role under "Company 2", e.g. "Administrate local users".
2. Check the permission "Administrate Local User Accounts".
3. Assign the local role to a Superior user under "Staff > "Additional Roles Company 2".
4. In order to create a new local users, there must be at least one role which can be assigned to local users. Open "Administration > Roles" and select a Role, e.g. "User". Click on "Edit Properties" and check "Allow user assignment for local administrators".

1. Login as Superior User which has the local role "Administrate local users".
   1. Navigate to OrgUnit "Company 2" and then choose "Local User Administration".
   2. Add a new local user. The user should appear as local user under "Company 2".

6.2.5 Export OrgUnits

Setup / Preconditions

1. Click on the Root node "Organisational Unit" and select "Export".
2. Create an export with "Simple XML Export".

1. Content of the XML file should look like this (beside the reference ids, they differ for each installation):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

<OrgUnits>
	<OrgUnit ou_id="68" ou_id_type="reference_id" ou_parent_id="__ILIAS" ou_parent_id_type="reference_id" action="create">
		<reference_id>68</reference_id><external_id>xyz</external_id><title>Company 1</title><description/>
	</OrgUnit>
	<OrgUnit ou_id="70" ou_id_type="reference_id" ou_parent_id="__ILIAS" ou_parent_id_type="reference_id" action="create">
		<reference_id>70</reference_id><external_id/><title>Company 2</title><description/>
	</OrgUnit>
	<OrgUnit ou_id="72" ou_id_type="reference_id" ou_parent_id="68" ou_parent_id_type="reference_id" action="create">
		<reference_id>72</reference_id><external_id/><title>Division 1</title><description/>
	</OrgUnit>
	<OrgUnit ou_id="74" ou_id_type="reference_id" ou_parent_id="68" ou_parent_id_type="reference_id" action="create">
		<reference_id>74</reference_id><external_id/><title>Division 2</title><description/>
	</OrgUnit>
	<OrgUnit ou_id="76" ou_id_type="reference_id" ou_parent_id="70" ou_parent_id_type="reference_id" action="create">
		<reference_id>76</reference_id><external_id/><title>Division 2</title><description/>
	</OrgUnit>
	<OrgUnit ou_id="78" ou_id_type="reference_id" ou_parent_id="70" ou_parent_id_type="reference_id" action="create">
		<reference_id>78</reference_id><external_id/><title>Division 1</title><description/>
	</OrgUnit>
	<OrgUnit ou_id="87" ou_id_type="reference_id" ou_parent_id="72" ou_parent_id_type="reference_id" action="create">
		<reference_id>87</reference_id><external_id/><title>Team 2</title><description/>
	</OrgUnit>
	<OrgUnit ou_id="89" ou_id_type="reference_id" ou_parent_id="72" ou_parent_id_type="reference_id" action="create">
		<reference_id>89</reference_id><external_id/><title>Team 1</title><description/>
	</OrgUnit>
	<OrgUnit ou_id="83" ou_id_type="reference_id" ou_parent_id="74" ou_parent_id_type="reference_id" action="create">
		<reference_id>83</reference_id><external_id/><title>Team 2</title><description/>
	</OrgUnit>
	<OrgUnit ou_id="85" ou_id_type="reference_id" ou_parent_id="74" ou_parent_id_type="reference_id" action="create">
		<reference_id>85</reference_id><external_id/><title>Team 1</title><description/>
	</OrgUnit>
	<OrgUnit ou_id="81" ou_id_type="reference_id" ou_parent_id="78" ou_parent_id_type="reference_id" action="create">
		<reference_id>81</reference_id><external_id/><title>Team 1</title><description/>
	</OrgUnit>
</OrgUnits>