.. -*- coding: utf-8 -*- ============= Configuration ============= :Author: Étienne Loks :date: 2012-10-08 :Copyright: CC-BY 3.0 This document presents the first steps to configure your Chimère. It has been updated for version 2.0.0. If an usage to the CLI is required, your session has to be initialised with these environment variables:: CHIMERE_PATH=/srv/chimere # change with your installation path CHIMERE_LOCALNAME=mychimere # change with your local project name CHIMERE_APP_PATH=$CHIMERE_PATH/$CHIMERE_LOCALNAME Once the application installed, there are a few simple steps to follow to configure *your* Chimère. Most of these steps are done in the web administration pages. If you are not familiar with *Django-like* administration pages you can look at the first paragraph of :ref:`administration` where it is presented. To access these pages you have to identify you with an account with *staff* and *superuser* status. A *superuser* account is created at the initialization of the database. Configuring the sites framework ------------------------------- *Sites* framework allow you to serve the same content on different domains. Most of you will probably use only one domain but this unique domain has to be configured. This is done in the web administration interface in *Sites > Sites* You only need to change *example.com* by your domain name. If you forgot to do that functionality such as RSS feeds will not work properly. .. _managing-areas: Managing areas -------------- An *Area* is the base of your map. It defines: * a name: a human readable label for this area. * an associated URN (*not mandatory*): the name of the area as a web ressource. In practice, if the area is not the default area the URN is used at the end of the default URL to access to this area. This is not mandatory but necessary for each area that is not the default one. * a welcome message (*not mandatory*): this message is displayed once a day per user arriving on the map. * an order (to sort areas). * an availability. * a default state. The /default/ area is viewed by default. Only one area can be the default: activating this state disable it on the possible other area with a default state. * default checked categories (*not mandatory*). * if categories are displayed dynamically (if dynamically is set, the end user only view categories witch have items on the map section the user currently see). * categories restriction (*not mandatory*): if no restriction is set all categories are available. * an external CSS file (*not mandatory*): an URL to an external CSS file. * restriction on the bounding box: if set to restricted, the end user can't pan outside the defined bounding box. Due to technical reasons, there is at this time no restriction on the zoom. * a map bounding box: this is the area to display when arriving on the map. If the area is restricted it will be the bounding box that restrict the end user. Hold the control key, click and drag to draw the bounding box. * available layers (*not mandatory* OSM Mapnik is used by default): OSM Mapnik render, OSM MapQuest render, OSM Transport Map render, OSM CycleMap are available by default. You can add new custom layer cf. :ref:`managing-layers`. *Areas* are customizable directly on the web administration interface in *Chimere > Areas*. As there is little chance that the default area should be appropriated for you, you'll have to set at least one default area. Adding many area can be a mean to show your map in different flavors. Managing users -------------- If you are not the only administrator/moderator of this Chimère installation you have to create and manage account for the other users. You can create a new *superuser* account with the CLI:: ./manage.py createsuperuser User password can be changed with the CLI (useful if you have forgotten your password):: ./manage.py changepassword username *Users* are customizable directly on the web administration interface in *Auth/User*. To create a new account, simply click on the Add button near Users. Give a name and a default password (the user can change it on in own later). Then complete the other pieces of information. Check the case: *Staff status* (or this user will not be able to log to the administration website). If this account is a new technical administrator, check *Superuser status* (this user must be trustworthy!). Otherwise you'll have to give permissions to this new user. It is easier to don't add permission manually but make this user member of a group. Two type of default group are proposed: application administrator and moderator. Moderator are limited to an *Area* (they only see items that are inside the bounding box). If a moderator manage many areas you'll have to select many groups. Detail of rights for default user/groups: +-----------------------------------------+-------------------------+---------------------------+-----------+ | Task | Technical administrator | Application administrator | Moderator | +=========================================+=========================+===========================+===========+ | User add/modify/delete | yes | no | no | +-----------------------------------------+-------------------------+---------------------------+-----------+ | Group add/modify/delete | yes | no | no | +-----------------------------------------+-------------------------+---------------------------+-----------+ | Property model add/modify/delete | yes | no | no | +-----------------------------------------+-------------------------+---------------------------+-----------+ | Import add/modify/delete | yes | no | no | +-----------------------------------------+-------------------------+---------------------------+-----------+ | Layer add/modify/delete | yes | no | no | +-----------------------------------------+-------------------------+---------------------------+-----------+ | News add/modify/delete | yes | yes | no | +-----------------------------------------+-------------------------+---------------------------+-----------+ | Area add/modify/delete | yes | yes | no | +-----------------------------------------+-------------------------+---------------------------+-----------+ | Icon add/modify/delete | yes | yes | no | +-----------------------------------------+-------------------------+---------------------------+-----------+ | Color/Color theme add/modify/delete | yes | yes | no | +-----------------------------------------+-------------------------+---------------------------+-----------+ | Category/Subcategory add/modify/delete | yes | yes | no | +-----------------------------------------+-------------------------+---------------------------+-----------+ | Point Of Interest add/modify/delete | yes | yes | yes | +-----------------------------------------+-------------------------+---------------------------+-----------+ | Route add/modify/delete | yes | yes | yes | +-----------------------------------------+-------------------------+---------------------------+-----------+ Creating property models ------------------------ A basic installation of Chimère permit to associate a name, a category, a description, dates, multimedia files, picture files, etc. for each geographic item. You may want to add more custom fields like phone number or opening hours. For that all you have to do is to add a new property model (*Chimere/Property model*). The administration page ask you for: * a name, * an order (to sort properties), * an availability to the end user (this can be used to set hidden properties), * a mandatory status, * the categories the property applied to (if no categories selected it applied to all), * the type: text, long text, password or date. To make this property available it is necessary to reload your web server (the property is cached). All forms are then automatically updated with this new field. If you don't want to allow add and modification of properties you can disable this form by setting CHIMERE_HIDE_PROPERTYMODEL to *True* in your *local_settings.py* file.