Core design

The main concept of a Cyclos implementation is the network. The idea of a network is to have an independent environment with a dedicated administrator (group) that has full permissions within the network scope. When a network administrator logs in the network environment it will appear to him/here as a single system.

Each Cyclos instance can have multiple, fully separate networks.

Core Cyclos elements

Each network is made up from the same core elements:

Users
Groups and group sets
Accounts
Products
Configurations
Channels

Users

Users are the only entities that can login to the system and perform actions such as payments. Users can have personal data such as profiles, transactions, advertisements, and one or more addresses and phone numbers.

Groups and group sets

A group is a container for users and contains little information. Groups can be added to a 'group set', which in its turn is just a container for one or more groups. The only thing that is defined in groups is which other groups users of this group can see.

A user can be part of only one Group or Group Set.

Accounts

Accounts in Cyclos can be either of the type "System" or "Member". Both types are related to a currency and can contain units that can be transferred to and from other accounts (if transaction types between these accounts exist).

If a new account with the type "Member" is created it is just an empty account type and cannot be accessed by members. In order to enable a member account an administrator will have to enter a member product and associate the new account to the product. By doing this all members with that product will have such a member account. Even though there is one member account configured each member will have their own account balance and their own payments.

Products

In Cyclos a 'Product' defines what users 'have' (certain accounts, profile fields) and what users 'can do' (e.g make payments, publish advertisements). Therefore products play a very central role in the Cyclos system. The product structure allows maintaining rules and permissions in a single entry points. This avoids having to duplicate settings and permissions among various groups.

A product can be assigned to an individual user, a group and a group set. Products can be of type member, broker and admin.

A user can have only one type. That means for example that a user with a member product can never do admin operations.

Products are 'cumulative'. This means that if a user has more than one product the sum of all permissions will be applied. In some rare cases this could lead to conflicting product configurations. But this is explained in the product page itself.

Simple systems could be configured in a way that there is a product for each group. For larger systems it is advisable to define products with functional boundaries. For example a 'Micro finance' product, or a product called 'Market place' that will have the common market place and advertisements permissions and settings.

A good approach is to create a good set of products first and after that assign them to groups according to the requirements. This approach will make the administration of the system more straight forward and transparent. An admin can always see from the user profile the 'final' (combined) product of the user in one overview page.

Configurations

Products are not well suited for the more static information such as the time zone, language, date format, content pages and layout. These elements can be defined in 'configurations'.

When a new configuration is created it can be bound to a group or group set. Where products are applied to users in a 'cumulative' way, configurations follow a hierarchical structure.

A configuration can 'extend' an existing configuration and the values defined in lower levels will overwrite the higher level configuration. All configurations descend directly or indirectly from the main configuration that is part of the default database, and cannot be removed. It is possible for an admin to define what options in a higher level configuration can be changed (overwritten) by lower level configurations. And define as well what configuration options are 'fixed', what means they cannot be modified at lower level configurations. This way specific configuration options can be forced down the configuration tree structure. Usually the more critical configuration options, such as max upload size, will be set as fixed and defined at a high level configuration. An admin can always see from the user profile the 'active' (combined) configuration that is applied to the user.The flexibility of the hierarchical configuration 'tree' avoids duplication and it is easier to maintain. It also allows to have multiple systems with various different layouts and contents in a single shared environment. Each (sub) system can have it's own configuration and define possible channels and layout elements.

Channels

Cyclos has various access Channels. We have adopted an approach where security is sensitive to the access channel. This means that users can enable and disable different levels of access security (registration, login, confirmation and one-time passwords) differently for every channel depending on their requirements.

The available channels are defined in Product. The configuration of the Channel, for example what password types are used, is defined in the Configuration.

General Concepts

You must be logged in to access this course