.. include:: /shortcuts.rstext .. index:: pair: Administration; Configure site single: Site administrator; Configure site .. _configure_site: Configure site ---------------- *Administration menu → Configure site* .. note:: *Configure site* is only accessible by site administrators. In *Configure site* you can: * set general parameters for your Mahara site * edit site pages * determine the display of certain menu items * allow networking with Moodle or another Mahara * create and share site pages and collections * upload site files .. index:: pair: Administration; Site options single: Site administrator; Site options .. _site_options: Site options ~~~~~~~~~~~~~~~~~~ *Administration menu → Configure site → Site options* In *Site options* you can set global options that will apply by default throughout the entire site. .. note:: One or more fields may be disabled if overridden by a setting in your config.php file. When you are done editing one or more settings, click the *Update site options* button at the bottom of the page. .. index:: pair: Administration; Site settings single: Site administrator; Site settings single: Drop-down site navigation .. _site_settings: Site settings ^^^^^^^^^^^^^^^^^^^ .. figure:: /images/administration/site_settings.* :alt: Site settings Site settings #. **Site name**: Choose a name for your Mahara instance. It appears in certain places around the site, e.g. in the title bar of the browser and in emails sent from the site. Therefore, it should not be too long. #. **Language**: Set the default language for your site. If you have multiple language packs installed, you see a drop-down menu. Otherwise, the standard language, English, is displayed. .. note:: You can install more `language packs `_. `More information about the language packs `_ is on the wiki. #. **Country**: The country selected is the default for country selections throughout your Mahara installation, e.g. in :ref:`contact information `. #. **Time zone**: :index:`Select ` the time zone in which you want to have time stamps displayed around the site. If you do not select one, one will be chosen according to the country if you entered one. This may not be accurate if a country has more than one time zone. #. **Theme**: Mahara comes with a number of themes that you can use. Choose one from the drop-down menu to make it the default theme for your site. If you have :ref:`institutions ` set up, they can :ref:`choose their own theme `. You can `search for community-contributed themes `_ on the Mahara wiki. #. **Show homepage / dashboard information**: If set to "Yes", information about Mahara and how it is used is displayed on the homepage for logged-out and on the *Dashboard* for registered users. Registered users can disable this for their own dashboard. See also :ref:`Quick links `. #. **Custom landing page**: :index:`Switch ` this setting to "Yes" if you want people to arrive at a different page than the dashboard after having logged in. The select menu where you can choose the appropriate page becomes visible. .. note:: If a person clicks a link that is different from the homepage and requires a login, they will be redirected to the proper page rather than being taken to the custom landing page. #. **Landing page**: Start typing a letter that appears in the title of the page that you want to choose. .. note:: Only group, institution, and site pages that are available to all registered users are displayed. That includes group homepages as well as group discussion forums when they are visible to all registered users. If a page is deleted or access removed, the site administrator receives an email notification so they can fix the problem. In the meantime, everybody is redirected to the dashboard page again. .. index:: Gravatar pair: Administration; User settings single: Site administrator; User settings single: Logged-in profile page access single: Staff report access single: Staff statistics access setting single: Device detection single: Responsive design single: Masquerading: Require reason single: Masquerading: Notify user .. _user_settings: .. _staff_report_access: .. _staff_statistics_access: .. _masquerading_reason_setting: .. _masquerading_notification_setting: .. _profile_completion_siteadmin: .. _export_to_queue: .. _anonymous_feedback: User settings ^^^^^^^^^^^^^^^^^^ .. figure:: /images/administration/user_settings.* :alt: User settings User settings #. **Users can choose page themes**: If this setting is enabled, users can select a theme for their portfolio page. The page is displayed with this theme to other users. Thus, the institution or site theme can be overwritten. #. **Display remote avatars**: If allowed, users' default profile pictures will be their `Gravatar `_ pictures (:ref:`remote avatar `). Users will need an account with Gravatar for this to work. .. note:: If you use your own avatar server to provide profile pictures for your users, you can use that instead of Gravatar for the default profile pictures. In order to do so, you need to add the :ref:`remote avatar base URL ` to your config.php. #. **Users can hide real names**: If allowed, users who have set a :ref:`display name ` may choose to be searchable only by their display name and will not be found in searches by their real name. In the administration section of the site, users are always searchable by their real names. An administrator (site and institution) always sees the display name, first and last name and username. #. **Never display usernames**: :index:`If set ` to "Yes", ordinary users cannot search for others using their username in "Search users" on the :ref:`dashboard ` or via :ref:`"People" `. They will also not be able to see the username of any other user. These restrictions do not apply to staff and administrators. Additionally, Clean URLs (if activated) for profile pages will be generated using display names (if provided) or real names, rather than usernames. #. **Show users in public search**: If allowed, :index:`usernames can appear in public search results `. In addition, this feature needs to have the :index:`value ` ``$cfg->publicsearchallowed = true;`` set in your config.php file and requires a search plugin that allows public search, e.g. Elasticsearch. .. note:: When you change this setting, you need to re-index the search index for the change to take effect. #. **Anonymous comments**: :index:`If allowed `, logged-out users / users without a login can leave comments on public pages or pages they can access via a secret URL. #. **Profile access for all registered users**: If this option is set to "No", profile pages are initially viewable by all registered users, but the owner is allowed to restrict access to their institution only if they wish. Enable this option if you want to make sure all users can see each others' profile pages. Profiles of institution members will always be visible to other members of the same institution. #. **Access reports for staff**: :index:`If ` set to "Yes", site and institution staff will have :ref:`access to user reports `. The following reports are available to them: * Masquerading sessions (if logging of these is turned on) * Portfolio access * User details #. **All reports for institution staff**: If set to "Yes", institution staff will have access to all reports in their institutions. This is normally restricted to administrators and site staff. #. **Users can disable device detection**: If allowed, users can disable mobile device detection in their :ref:`account settings `. This allows them to be more flexible in what they can view and do on a mobile device such as a smartphone or tablet. #. **Require reason for masquerading**: If set to "Yes", administrators will be required to enter a reason for :ref:`masquerading as other users `. This will be logged, and if the setting "Notify users of masquerading" is enabled, included in the notification to the user about the masquerading. This setting needs :ref:`logging ` to be turned on. #. **Notify users of masquerading**: If set to "Yes", users will be notified :ref:`when an administrator masqueraded as them `. The notification will include who, when and - if enabled under "Require reason for masquerading" - why. This setting needs :ref:`logging ` to be turned on. #. **Show profile completion**: If set to "Yes", :index:`a progress bar with tips ` about what to complete in the user profile will be displayed in the sidebar to users. They can disable it in their :ref:`account settings `. .. seealso:: Administrators can configure the items that count towards profile completion in *Administration menu → Institutions →* :ref:`Profile completion `. #. **Export to queue**: :index:`If allowed `, the export queue will handle the exporting of user portfolios via Leap2A for better server load management. .. note:: **This feature is still experimental.** Turning this feature on will export individual portfolios in *Main menu → Manage → Export* via the export queue. That means that the export is made when there are enough system resources available. The user exporting a portfolio will receive an email when the export is ready for download. #. **Multiple journals**: If allowed, :index:`all users ` will have multiple journals per default. They can still change that setting in their personal account settings. .. index:: pair: Administration; Search settings single: Site administrator; Search settings .. _search_settings: Search settings ^^^^^^^^^^^^^^^^^^ Mahara comes with a search plugin that allows you to search for users and pages. If you install another search plugin, you will be able to select which one to use for your site. .. figure:: /images/administration/search_settings.* :alt: Search settings Search settings .. seealso:: You can configure the internal search plugin in the :ref:`administration of the search plugin `. Elasicsearch is another search plugin that is supported by Mahara out of the box. The search server will need to be installed separately though. Elasticsearch is useful for fulltext search and is required for advanced reporting. .. note:: You need to choose the Elasticsearch plugin if you turn on :ref:`"Event log reporting" `. .. index:: Public group, Group category pair: Administration; Group settings single: Site administrator; Group settings .. _group_settings: Group settings ^^^^^^^^^^^^^^^^^^^^ Mahara cannot only be used for individual work but also to work collaboratively in groups. Some settings are available in that area. .. figure:: /images/administration/group_settings.* :alt: Group settings Group settings #. **Create groups**: You decide whether administrators, administrators and staff or everyone can create groups. The default setting is the most permissive "everyone" because Mahara is user-centered and gives the individual users a great deal of control over what they want to do. If you choose to limit the group creation to administrators (and staff), these need to be contacted to set up groups. There is no internal group request system. #. **Create public groups**: Choose whether everyone or only administrators can create :ref:`public groups `. These are groups for which you do not need to be a member of the group or even have a login for Mahara to view the group homepage, discussion forums (and member listing if the group administrator allowed that). #. **Allow group categories**: If allowed, site administrators can create categories for users to assign to their groups. These categories can be used to filter groups in :ref:`Groups `. .. seealso:: Group categories are managed by site administrators in the :ref:`groups area ` of the administration. #. **See own groups only**: :index:`This ` setting becomes active when the site is set to :ref:`"Isolated institutions" `. This setting makes it possible for people to only see other people who are in the same groups. They cannot see other groups in the search results. .. index:: Multiple institutions; Institution expiry; Auto-suspend expired institutions pair: Administration; Institution settings single: Site administrator; Institution settings .. _institution_settings: Institution settings ^^^^^^^^^^^^^^^^^^^^^^^^ You can use Mahara with multiple institutions and separate them for administrative purposes, e.g. user management and permissions, and to give them a different theme. .. figure:: /images/administration/institution_settings.* :alt: Institution settings Institution settings #. **Strict privacy**: You may want to require all your users to accept the terms and conditions and privacy statement on your site. Switch this setting to "Yes" if you want to have more control over the acceptance. You cannot allow multiple institutions if you want to use this setting for the time being. .. note:: The strict privacy feature was created to help institution comply with the `GDPR `_ in the European Union. However, institutions that do not need to adhere to it may find it useful as well. Turning this setting on will require everyone on the site to accept the terms and conditions and privacy statement(s) the first time they log in as well as whenever they change. #. **Users allowed multiple institutions**: If allowed, users can be members of several institutions at the same time. Thus, a user who belongs to two or more institutions only needs one account. You cannot allow multiple institutions when "Strict privacy" is turned on and when the site has isolated institutions. .. note:: While this is a convenient setting for people who need to be institution administrators in multiple institutions and cannot receive site administrator permissions, it is recommended that users can only belong to one institution. #. **Confirm registration**: :index:`If set to "Yes", administrators ` cannot make the *Confirm registration* setting optional when :ref:`configuring an institution `. This prevents institution administrators from disabling this setting when it is required site-wide to not allow user accounts to be created without administrator approval. .. note:: When registration needs to be confirmed, people trying to register with an institution need to provide a reason. #. **Warning time for institution expiry**: If set, a notification will be sent to site and institution administrators this amount of time before an institution is due to expire and be suspended. This time may be specified in days, weeks, months, years or "No end date". If the latter option is chosen, institutions will not expire by default. #. **Auto-suspend expired institutions**: If set to "Yes", this option will allow Mahara to automatically suspend an institution that has expired automatically. This means that users of that institution will not be able to log in until the institution has been unsuspended. #. **Review accounts before self-deletion**: If set to "Yes", every institution is forced to approve or deny the deletion of accounts if users attempt to delete their account. If set to "No", it is up to each institution to activate this setting. .. note:: This setting gives institutions in a formal learning setting the possibility to prevent accidental account deletion by people before portfolios are archived if required. .. index:: Default account lifetime, Default account inactivity time, Session lifetime, Warning time for inactivity / expiry pair: Administration; Account settings single: Site administrator; Account settings single: Account settings; Default registration expiry lifetime single: Account settings; Override user account lifetime .. _config_site_account_settings: Account settings ^^^^^^^^^^^^^^^^^^^^^^ .. figure:: /images/administration/account_settings.* :alt: Account settings Account settings #. **Session lifetime**: For security reasons, after a specified period of inactivity, a user will be logged off the site automatically. This field specifies this time in minutes. The default value is 1440 minutes (24 hours). #. **Default registration expiry lifetime**: As site administrator you can decide when :ref:`pending registrations ` that require approval expire. This time may be specified in days, weeks, months, years or "No end date". If the latter option is chosen, pending registrations will not expire by default. The default value is 2 weeks. #. **Default account lifetime**: If set, user accounts will expire after this amount of time from when they were created. When a user account is expired, the user cannot log in. This time may be specified in days, weeks, months, years or "No end date". If the latter option is chosen, accounts will not expire by default. #. **Override user account lifetime**: Choose for which accounts a :index:`change in the default account lifetime ` shall take effect: * Only for newly created users * For new users and users without an account lifetime already set (excluding site administrators) * For all user accounts (excluding site administrators) .. note:: Site administrators are always excluded from a change in the account lifetime as they should always have access to the system. #. **Default account inactivity time**: If set, users who do not log in for this amount of time will be considered "inactive" and will not be able to log in anymore. This time may be specified in days, weeks, months, years or "No end date". If the latter option is chosen, users are not set to "inactive" by default. #. **Warning time for inactivity / expiry**: If set, a warning message will be sent to users this amount of time before their accounts are due to expire or become inactive. This time may be specified in days, weeks, months, years or "No end date". If the latter is chosen, users do not receive a warning before their account expires or they are flagged as having an inactive account. .. index:: Virus checking, ClamAV, Anti-spam, External resources in HTML pair: Administration; Security settings single: Site administrator; Security settings single: Spam protection; reCAPTCHA .. _security_settings: Security settings ^^^^^^^^^^^^^^^^^^^^^ .. figure:: /images/administration/security_settings.* :alt: Security settings Security settings #. **Password policy**: :index:`Select ` the minimum requirements for passwords by people who use internal authentication. The password policy does not affect accounts using external authentication such as SSO or LDAP for example. You need to select a minimum password length and also the make-up of the password. The options are: * Upper and lowercase letters * Upper and lowercase letters, numbers * Upper and lowercase letters, numbers, symbols .. note:: Along with the password policy, a password strength indicator is available on fields where a new password needs to be entered in order to show how good the new password is. #. **Virus checking**: If you want all files that are uploaded by users to be run through the ClamAV virus scanner, you should turn the virus checking option on. You have to have `ClamAV `_ installed on your server. #. **Path to ClamAV**: For security reasons, the :index:`path to ClamAV ` on your server needs to be provided in the :ref:`config file `. You see the path here if you provided that config value. #. **Anti-spam**: There are three levels of anti-spam protection available for publicly visible forms such as the contact and registration forms. A form submission is never silently rejected. Rather, an error message is displayed asking the user to try again if the submission is classified as spam. The three choices are: * **None**: No anti-spam checks are performed on form submissions. * **Simple**: Some basic checks are performed. Form submissions with email addresses that are not well-formed or that have an excessive number of URLs are rejected. * **Advanced**: Performs additional checks to determine whether email addresses are real or contain URLs that are blacklisted. This requires an Internet connection. #. **Spamhaus URL blacklist**: If set to "Yes", URLs will be checked against the Spamhaus DNSBL. The `Spamhaus Project `_ provides a URL blacklist that is free for non-commercial, low-traffic use. A professional use datafeed service is also available but not supported in Mahara. Please read the `Spamhaus DNSBL usage terms `_ before enabling this option. #. **SURBL URL blacklist**: If set to "Yes", URLs will be checked against the SURBL DNSBL. `SURBL `_ provides a URL blacklist that is free for organizations with fewer than 1000 users. A professional use datafeed service is also available, but not supported in Mahara. Please read the `SURBL usage terms `_ before enabling this option. #. **Disable external resources in user HTML**: Turning this option on will prevent users from embedding external resources such as images from remote sites into their forum posts and other HTML content. YouTube videos and other media can also not be embedded. It is however a good thing to do from a security standpoint since it does neutralise a few clever phishing attacks. See the `HTML Purifier documentation `_ for more details. #. **reCAPTCHA on user registration / contact us forms**: If set to "Yes", :index:`people who register themselves on the site ` and who use the "Contact us" form when not logged in are required to fill in the `reCAPTCHA `_ form. This is for spam protection. #. **reCAPTCHA site key**: Enter the site key for your site's reCAPTCHA account. #. **reCAPTCHA secret key**: Enter the secret key for your site's reCAPTCHA account. .. index:: pair: Administration; Proxy settings single: Site administrator; Proxy settings .. _proxy_settings: Proxy settings ^^^^^^^^^^^^^^^^^^ .. figure:: /images/administration/proxy_settings.* :alt: Proxy settings Proxy settings #. **Proxy address**: If your site uses a proxy server to access the Internet, specify the proxy in ``hostname:portnumber`` notation. #. **Proxy authentication model**: Select your proxy's authentication model (none or basic [NCSA]), if appropriate. #. **Proxy credentials**: Enter the credentials required for your proxy to authenticate your web server in ``username:password`` format. .. index:: System mail address pair: Administration; Email settings single: Site administrator; Email settings single: Default notification method .. _email_settings: Email settings ^^^^^^^^^^^^^^^^ .. figure:: /images/administration/email_settings.* :alt: Email settings Email settings #. **SMTP host**: If you want to force Mahara to use a specific SMTP server instead of the system one, enter its hostname here, e.g. ``smtp.example.com``. It is possible to specify more than one host by separating them with semicolons, e.g. ``smtp1.example.com;smtp2.example.com``, but keep in mind that all other settings, e.g. authentication credentials and port numbers, will apply to all listed servers. It is not possible to specify different credentials for each server in this list. This feature is useful when SMTP host authentication is not required or you list different frontends for the same mail server in which case other settings will work. #. **SMTP port**: If your SMTP server uses a port number different from 25, you may specify it here. When encryption is enabled, the default ports are 465 for SSL and 587 for TLS. You only need to specify a port number if it is different from these. Check the correct settings with your mail service provider. #. **User**: If your SMTP server requires authentication, enter the username here. #. **Password**: If your SMTP server requires authentication, enter the password here. #. **SMTP encryption**: If your SMTP server supports encryption, enable it here. #. **System mail address**: This email address is the address that emails are sent from Mahara. .. index:: pair: Administration; Notification settings .. _notification_settings: Notification settings ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ You can set the default options for new users to receive notifications. Users can override these settings on their own *User menu → Settings → Notifications* page. The options you have are: * **Email**: Sends an email to your primary email address once the notification was created. In some cases, the cron needs to run first in order for the notification to be sent. * **Email digest**: Sends one email per day for all the notifications that you set to "Email digest". .. note:: If you select either of the email options, notifications will still arrive in the user's inbox, but they will be marked as read automatically. * **Inbox**: All notifications are only sent to your system inbox that you can reach in the top right corner next to the "Logout" button. * **None**: If you use this option, you will not get a notification for the selected notification type. Use this setting wisely as you may miss important notifications. .. note:: You cannot set "System messages" and "Messages from other users" to "None". .. figure:: /images/administration/notification_settings.* :alt: Notification settings Notification settings #. **Internal notification expiry**: :index:`The ` number of days until certain notifications in the inbox are deleted. The default value is 182 days. The notifications in question are: * Page access notifications * Watchlist notifications * Institution messages #. **Contact us**: Only site administrators see this notification type. These are messages sent via the "Contact us" form that can be accessed in the footer of the site if the site administrators :ref:`decided to display this link