Prev   Next

4.3. webapp/WEB-INF/src/serviceconfig

Most of the spring read configuration files are within this directory structure. There are three types of configuration files to find here and a simple mechanism of overwriting default values with your customized ones. In this installation and administration guide only the configuration files and their meaning is outlined. The build.properties file is copied to the webapp/WEB-INF/classes/serviceconfig during the build process. This is needed, because the spring config files make use of the defined property values.

Caution

Always propagate changes to the build.properties with an ant config-all copy-resources and a restart of tomcat.

The three types

Overriding mechanism

brasatoconfig.xml

Basic settings from build.properties injected in various classes by spring. Here the list of AJAX accepted user agent strings is defined.

org/olat/_spring/brasatoconfigpart.xml

Defines a mapping of paths to dispatchers in <bean id="org.olat.core.dispatcher.Dispatcher"...

Some examples are:

  • /dmz/ refers to dmzbean which loads and configures the org.olat.dispatcher.DMZDispatcher

  • /auth/ refers to authbean which loads and configures the org.olat.dispatcher.AuthenticatedDispatcher

org/olat/_spring/olat_userconfig.xml

This feature was started, designed and developed by BPS Bildungsportal Sachsen and finished by Frentix . The last tests and fixes were done by MELS .

This configuration file defines the user attributes available and mandatory/optional, moreover it is the place where their usage is specified. This means you can remove, add, rename user attributes, and also define their availability in different forms, tables/listings, and read only views here.

Three important points to mention first:

  • Each new release means that you must track the changes in this configuration and act accordingly - e.g. adding of new forms, removing forms, etc.

  • This custom fields may not only appear in forms and read only views. There are table data models, bulk imports, exports, configuration managers to be taken into account. Thus it is a configuration to be tested, and thought about twice.

  • Search with custom fields works only for the users having those user fields filled.

The configuration file consists of three parts. First of all there is a list of User properties defining at least a name , group and deletable boolean value. Then there is a list of code places which are user property enabled. Hence you can configure each table, form, read only view with the set of user properties visible. In the first part the implementation for the org.olat.user.UserManager is specified.

The three parts

  • The property name="userPropertyHandlers" in the bean id="org.olat.user.UserPropertiesConfig" contains the list of available user properties in the system.

  • The property name="userPropertyUsageContexts" in the bean id="org.olat.user.UserPropertiesConfig" defines where the user properties are used.

  • The bean id="org.olat.user.UserManager" defines which user manager implementation is used - you probably do not change this.

The following examples introduce the concepts used:

Example 4.1. Definition of a user property

<bean name="userPropertyFirstName" class="org.olat.user.propertyhandlers.Generic127CharTextPropertyHandler"> 1
	<property name="name" value="firstName" /> 2 
	<property name="group" value="account" /> 3
	<property name="deletable" value="false" /> 4
</bean>

1

The beans name must be unique over all properties, the class refers to a java class responsible for handling input, output, and validation. This Generic127CharTextPropertyHandler needs the three values initialized via spring properties - name, group, deletable.

2

name i18n key for translation

3

group you can group properties together, e.g. address if your property belongs to address information

4

deletable if the value can/should be deleted in case the user is deleted. Should be true in most cases.


Example 4.2. userPropertyHandlers is a list of previous defined properties

<bean id="org.olat.user.UserPropertiesConfig" class="org.olat.user.propertyhandlers.UserPropertiesConfigImpl">
	<property name="userPropertyHandlers"> 1
		<list>
			<ref bean="userPropertyFirstName" />	2
			<ref bean="userPropertyLastName" />
			<ref bean="userPropertyEmail" />
			<ref bean="userPropertyBirthDay" />
			<ref bean="userPropertyGender" />
			<ref bean="userPropertyTelPrivate" />
			<ref bean="userPropertyTelMobile" />
			<ref bean="userPropertyTelOffice" />
			<ref bean="userPropertySkype" />
			<ref bean="userPropertyHomepage" />
			<ref bean="userPropertyStreet" />
			<ref bean="userPropertyExtendedAddress" />
			<ref bean="userPropertyPoBox" />
			<ref bean="userPropertyZipCode" />
			<ref bean="userPropertyRegion" />
			<ref bean="userPropertyCity" />
			<ref bean="userPropertyCountry" />
			<ref bean="userPropertyInstitutionalName" />
			<ref bean="userPropertyInstitutionalUserIdentifier" />
			<ref bean="userPropertyInstitutionalEmail" />
			<ref bean="userPropertyOrgUnit" />
			<ref bean="userPropertyStudySubject" />
		</list>
	</property>

1

It as simple as it looks - it is just a list of previously defined user properties

2

added userProptertyFirstName and userPropertyLastName. Make sure if you add your own, that you list them here.


Example 4.3. Home settings configuration

<bean id="org.olat.user.UserPropertiesConfig" class="org.olat.user.propertyhandlers.UserPropertiesConfigImpl">
	<property name="userPropertyHandlers">
		<list>
			<ref bean="userPropertyFirstName" />
			<ref bean="userPropertyLastName" />
			.
			.
			.
			<ref bean="userPropertyStudySubject" />
		</list>
	</property>		
	<property name="userPropertyUsageContexts">
		<map>
			<!-- 
				Forms that show user properties
			-->
			<entry key="org.olat.user.ProfileForm"> 1
				<bean class="org.olat.user.propertyhandlers.UserPropertyUsageContext">
					<property name="propertyHandlers"> 2
						<list>
							<ref bean="userPropertyFirstName" />
							<ref bean="userPropertyLastName" />
							.
							.
							.
							<ref bean="userPropertyStudySubject" />
						</list>
					</property>
					<property name="mandatoryProperties"> 3
						<set>
							<ref bean="userPropertyFirstName" />
							<ref bean="userPropertyLastName" />
							<ref bean="userPropertyEmail" />
						</set>
					</property>
					<property name="userViewReadOnlyProperties"> 4
						<set>
							<ref bean="userPropertyFirstName" />
							<ref bean="userPropertyLastName" />
							.
							.
							.
							<ref bean="userPropertyStudySubject" />
						</set>
					</property>
					<property name="adminViewOnlyProperties"> 5
						<set />
					</property>
				</bean>
			</entry>

1

The configuration affects the users profile form. If this is not documented, you must use the java IDE to find the class and corresponding GUI workflow. The following descriptions refer to this form now.

2

The list of properties are shown as input fields in the specified order to the user.

3

The set of properties are mandatory and a validity check for a not empty semantic is called on each property.

4

This set defines which properties are only in read-only mode for the user.

5

The last set are the properties visible to administrators only. Make sure you do not have them here and also in read-only for users list.


org/olat/_spring/olatextconfig.xml

The interesting configuration parts are, and simply ignore the rest:

Layout defining controllers for header, topnav and footer

  • id="fullWebApp.HeaderControllerCreator" defines layout and work flows for the header part.

  • id="fullWebApp.TopNavControllerCreator" defines layout and work flows for the top nav part.

  • id="fullWebApp.FooterControllerCreator" defines layout and work flows for the footer part.

org/olat/core/_spring/olatcoreconfig.xml

Bootstrap for the olatcore, mainly for services which have to be configured, created before anything else happens.

org/olat/core/commons/scheduler/_spring/olatdefaultconfig.xml

Default values of the scheduler. This file is inside of the olat-core.jar and own values must be specified in the olatextconfig.xml

org/olat/core/commons/scheduler/_spring/olatextconfig.xml

Defines the scheduled jobs used inside of OLAT, if you have a job to be scheduled, add it here.

org/olat/ldap/_spring/olatextconfig.xml

See also build.properties file for LDAP basic settings.

org/olat/commons/modules/glossary/_spring/olatdefaultconfig.xml

TODO

org/olat/commons/coordinate/cluster/_spring/olatdefaultconfig.xml

TODO

org/olat/admin/sysinfo/_spring/olatdefaultconfig.xml

TODO

org/olat/course/auditing/remote/_spring/olatdefaultconfig.xml

TODO

org/olat/search/service/_spring/olatdefaultconfig.xml

TODO

org/olat/shibboleth/_spring/olatdefaultconfig.xml

TODO

org/olat/notifications/_spring/olatdefaultconfig.xml

TODO

Prev Up Next
 Home