Customize the application

The application can be customized in the following manners: functionalities, UI metadata and data model extensions.

The functionalities will be attached to the role and the theme, and the UI metadata will be attached to all the elements of the theme.

They should be configured in the vars file, in the admin_interface / available_functionalities or respectively available_metadata. It is a list of objects which have a name and a type.

The type can be:

Check CONST_vars.yaml for examples of usage.

In order to inherit the default values from CONST_vars.yaml, make sure the update_paths section contains the item admin_interface.available_functionnalities or respectively admin_interface.available_metadata.

URL

In the admin interface, we can use for all URL definitions the following special schema:

  • static: to use a static route,

    • static:///icon.png will get the URL of the static-ngeo static route of the project.
    • static://static-cgxp/icon.png will get the URL of the static-cgxp static route of the project.
    • static://prj:img/icon.png will get the URL of the img static route of prj.

  • config: to get the server name from the URL, with the config from the vars file:

    servers:
   my_server: http://example.com/test

    config://my_server/icon.png will be transformed into the URL http://example.com/test/icon.png.

Functionalities

c2cgeoportal provides the concept of functionality that can be used to customize the application according to the user’s permissions.

A functionality may be associated to users through different ways:

  1. Functionalities for anonymous users are defined through the functionalities:anonymous variable in the vars_<project>.yaml configuration file.
  2. Functionalities for authenticated users are defined through the functionalities:registered variable in the vars_<project>.yaml configuration file.
  3. Functionalities for specific roles are defined in the database through the administration interface.
  4. Functionalities for specific users are defined in the database through the administration interface.

Each level overrides the previous ones in the order indicated above. For example, if the user is authenticated and has associated functionalities in the user database table, then the functionalities:anonymous and functionalities:registered configuration variables, as well as any functionality associated with his/her role, will be ignored.

Configuration

The vars_<project>.yaml file includes variables for managing functionalities.

admin_interface/available_functionalities

List of functionality types that should be available in the administration interface (and added to the functionality table in the database).

For example:

admin_interface:
    available_functionalities:
    - default_basemap
    - print_template
    - mapserver_substitution

The following syntax is also accepted:

admin_interface:
    available_functionalities: [default_basemap, print_template, mapserver_substitution]
functionalities:anonymous

Functionalities accessible to anonymous users. This is a list of key/value pairs, whose values are either arrays or scalars.

For example:

functionalities:
    anonymous:
        print_template:
        - 1 A4 portrait
        - 2 A3 landscape
        default_basemap: plan

In this example, anonymous users can print maps using the 1 A4 portrait and 2 A3 landscape layouts only. Their default base layer is the plan layer.

functionalities:registered
Functionalities accessible to any authenticated user. This is a list of key/value pairs, of the same form as for functionalities:anonymous.
functionalities:available_in_templates

Functionalities that are made available to Mako templates (e.g. viewer.js) through the functionality template variable.

For example with:

functionalities:
    available_in_templates:
    - <functionality_name>

if a user is associated to, say, <functionality_name>/value1 and <functionality_name>/value2, then the functionality template variable will be set to a dict with one key/value pair: "<functionality_name>": ["value1","value2"].

Usage in Templates

As explained in the configuration section above, a functionality can be used in the Mako templates as long as it has been enabled using the functionalities:available_in_templates parameter in the vars_<project>.yaml configuration file.

Functionalities may be used in templates for various purposes. The examples below explain how to set the default basemap and how to limit access to some plugins according to the user’s permissions.

Example of the default_basemap Functionality

Using functionalities, you can set the default basemap that will be displayed when a user loads the application depending on whether he/she is anonymous, authenticated or has some specific role.

First, make sure that default_basemap is made available in the templates using the functionalities:available_in_templates parameter in the vars_<project>.yaml configuration file:

functionalities:
    available_in_templates: [default_basemap]

Then indicate (still in vars_<project>.yaml) what default basemap should be used for anonymous users:

functionalities:
    anonymous:
        # some other configs...
        default_basemap: <some_basemap>

Optionally, you may also indicate what basemap to use for authenticated users (if omitted, the anonymous default_basemap value will be used):

functionalities:
    anonymous:
        # ...
    registered:
        default_basemap: <some_other_basemap>

Finally, you may link default_basemap functionalities to some roles or users in the administration interface.

If you are using the cgxp_mapopacityslider plugin, use the following configuration in your project’s viewer.js template so that the default_basemap is provided there:

{
    ptype: "cgxp_mapopacityslider",
    defaultBaseLayerRef: "${functionality['default_basemap'][0] | n}"
}

Using Functionalities to configure the basemap to use for each theme

A default basemap may be automatically loaded when the user selects a given theme.

Then, in the administration interface, if not available yet, define a default_basemap functionality containing the basemap reference. Edit the theme and select the basemap to load in the default_basemap list. If several default_basemap items are selected, only the first one will be taken into account.

Extend the data model

The data model can be extended in the file <package>/models.py and the corresponding admin interface configuration in the file <package>/forms.py.

For example, to add some user details, including a link to a new class named “Title”, add to <package>/models.py:

# Used to hide the original user in the admin interface
User.__acl__ = [DENY_ALL]

class UserDetail(User):
    __label__ = _('userdetail')
    __plural__ = _('userdetails')
    __tablename__ = 'userdetail'
    __table_args__ = {'schema': _schema}
    __acl__ = [
        (Allow, Authenticated, ALL_PERMISSIONS),
    ]
    __mapper_args__ = {'polymorphic_identity': 'detailed'}
    id = Column(types.Integer, ForeignKey(_schema + '.user.id'),
            primary_key=True)

    phone = Column(types.Unicode, nullable=False, label=_(u'phone'))

    # title
    title_id = Column(Integer, ForeignKey(_schema + '.title.id'), nullable=False)
    title = relationship("Title", backref=backref('users'))

    def __init__(self, username=u'', password=u'', functionalities=[],
                 phone=u'', email=u'', title=None, role=None):
        User.__init__(self, username, password, email, functionalities, role)
        self.phone = phone
        self.title = title

class Title(Base):
    __label__ = _('title')
    __plural__ = _('titles')
    __tablename__ = 'title'
    __table_args__ = {'schema': _schema}
    __acl__ = [
        (Allow, Authenticated, ALL_PERMISSIONS),
    ]
    id = Column(types.Integer, primary_key=True)
    name = Column(types.Unicode, nullable=False, label=_(u'Name'))
    description = Column(types.Unicode, label=_(u'Description'))

    def __init__(self, name=u'', description=u''):
        self.name = name
        self.description = description

    def __unicode__ (self):
        return self.name or u''