Chapter 6. The [fleXive] core components

Table of Contents

User Management
Creating a user
Updating a user
Removing a user
Authentication / FxContext / UserTickets
ACLs - Access Control Lists
Role Based Security
Structure Engine
Root Type
Type parameters
Creating a new type
Data types
Handling binary content
Select lists
Select list parameters
Select list item parameters
Select list creation and persistance
Select list item permissions
Properties and property assignments
Conceptual explanation of property assignments
Property parameters
Uniqueness of values
Groups and group assignments
Group parameters
Group modes
Property and group options
The GroovyTypeBuilder
GroovyTypeBuilder Syntax
GroovyTypeBuilder Attributes
Property and Group Creation - Default Values
GroovyTypeBuilder Usage Examples
The GroovyOptionBuilder
Content Engine
Using FxContent
Primary keys and versions
Search Engine
An introduction to FxSQL
Select user-defined columns
Select all columns
Fulltext search
Properties versus assignments
Content permissions
Lock information
Tree Search
Briefcase Search
Date and Time Functions
Type conditions
Select list properties
Resolving system properties
Order by
Operator table
Literal value formatting
SqlQueryBuilder: Building queries in Java
Nested conditions
Search parameters
The Groovy query builder
Working with search results
Accessing result rows
Briefcase Engine
Tree Engine
Edit and Live modes
Scripting Engine
Events and Bindings
Run-Once and Startup Scripts
Workflow Engine
Conceptual Overview
Creating and updating workflows
Configuration Engine
Conceptual Overview
Working with configuration parameters
Object parameters

If you remove all eyecandy created by more or less sophisticated user interfaces you will discover the driving force behind [fleXive]: the core layer. It is implemented at the EJB layer and is provided by stateless session beans. These engines serve as abstractions to concrete implementations (usually using some form of singleton pattern) for different databases or algorithms used.

The areas covered are structure definition, content manipulation, SQL like queries, organizing contents in trees, scripting, workflow, user management and how security is handled.

Handling users and user information is a basic business of virtually every major software system in use today. At this juncture [fleXive] is no exception. User management in [fleXive] is based on accounts – that is a user and its basic information (name, login name, contact data, e-mail addresss, ...) are stored in accounts.

In the table below you see the listing of all attributes an account in [fleXive] owns.

Table 6.1. Account Attributes
Attribute Description
id, name, login name, e-mail, description, contactDataId Some basic attributes. The Id uniquely identifies the account. The description allows you to characterize the account while the contactDataId identifies the contact data (e.g. postal address, telephon number) linked to this user. Name and login name stand for themselves.
mandatorId The mandator the account belongs to. Note that every account has to be assigned to exactly one mandator.
language Identifies the preferred language for the account. Whenever there are available user interface translations or contents in several languages the system will select to display the ones in the language specified here, if available.
active An account can be set to status inactive. Thus no login is possible while it is not activated again. Note: both flags, active and validated, have to be set to true for the login to work.
validated Flags for admins indicating that the user data was audited and is no fake. Setting this flag to false prevents a login for the corresponding account until the flag is set to true. This setting can be used when auto-creating accounts to force validation of the account data. Note: both flags, active and validated, have to be set to true for the log in to work.
validFrom, validTo The valid from/to dates may be used to define a time periode in which the user may log in.
defaultNodeId The desired start node in the tree for the user.
allowMultiLogin True if multiple logins for the account are possible at the same time.
updateToken The update token may be used in external API calls modifying this account to improve security.

There are two system defined accounts:

  • the guest user. Everyone who is not logged in is treated as GUEST.

  • the supervisor. This user is in all roles and may operate on all mandators.

These two accounts can not be removed.

In the following we will look at how to create, update and remove accounts.

Creating a user requires special rights. More precisely only callers (i.e. a user) in role ACCOUNT MANAGEMENT may create users, and only for their mandator. An exception is a user in the role GLOBAL_SUPERVISOR who may create users for all mandators. An example of how to create a new user is given next.

After the account creation one can assign the roles the account is in and the groups it belongs to. For a detailed explanation of the meaning and functioning of roles and groups refer to the the section called “Security”.

For assigning a role to an account the following rules apply:

  • the caller must be in role ACCOUNT MANAGEMENT

  • the account/user has to belong to the callers mandator

  • the caller may only assign roles that he is assigned to himself

GROUP_GLOBAL_SUPERVISOR may set the roles for all users in the system.

Assigning a group to an account presumes the following prerequisites:

  • the caller must be in role ACCOUNT MANAGEMENT

  • the account/user has to belong to the callers mandator

  • the caller may only assign groups that also belong to his mandator, plus GROUP_EVERYONE and GROUP_OWNER

GROUP_GLOBAL_SUPERVISOR may set all groups for all users. Note that by default a newly created account is assigned to the group EVERYONE. To get more information about groups go to the the section called “Security”.