Flux Database/Printable version

Flux Database

The current, editable version of this book is available in Wikibooks, the open-content textbooks collection, at

Permission is granted to copy, distribute, and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike 3.0 License.

Creating a shared workspace

To create a new shared workspace after launching the application, tap the + button above the list of workspaces and enter a name for the new workspace. You can create as many workspaces as you wish. When you create a new workspace, you'll be the only member and have the manager role. Only managers can invite other members and edit the database structure and access rights.

Newly created workspaces contain a few data forms and views to illustrate how to define the database structure and associated access rights. You can modify or replace the defining XML code.

You can leave a workspace by tapping the trash icon or swiping to the left in the list of workspaces. After leaving a workspace you will no longer have access to the workspace's data. Other members will be able to continue using the workspace. Orphaned workspaces are deleted.

Inviting users to workspaces

You need to have the manager role to invite users to a workspace. Open the workspace and tap the Invite button. Enter a substring of the user's name of email address. Tap the list item with the name of the user you want to invite to the workspace. The user can accept or reject the invitation.

If a user accepts an invitation, they'll have the member role. You can change the user's role and add him or her to user groups in order to grant him or her access rights to data records. Users can decide to leave a workspace.

Before you invite a user, he or she must have the Flux application installed on his or her device. New users need to launch the application at least once in order to create a user account and be discoverable via their name or email address.

Designing the database structure

Workspaces consist of custom data forms and views. You can freely design the structure of the data forms, such as their data fields and relationship with views, and assign fine-grained access rights to groups of users. The database structure is defined in a single XML file.

To define a data form, use the Form tag. Every form needs to have an identifier and you can optionally provide a title. If no title is given, the identifier is used as the title.

Forms consist of data fields. In the following example, the Title field is of type text, i.e., a simple text field. The Author field is of type reference, which means that it refers to records from the view specified by the refview attribute. The reffields attribute lists the fields that will be displayed in the corresponding select box.

<Form id="Book">
  <Field id="Author" type="reference" refview="Authors" reffields="LastName, FirstName"/>
  <Field id="Title"/>
  <ReadAccess groups="admin;member"/>
  <EditAccess groups="admin;member"/>
  <CreateAccess groups="admin;member"/>

Every form is associated with a list of groups, whose members can use the form to read, create, author and edit records. Readers can merely read records. Creators can create records but they can't edit them. Authors can create records and edit or delete their own records (i.e., the records created by them). Finally, editors can edit and delete all records.

Views, defined using the View tag, consist of columns that refer to data fields of the form specified by the form attribute.

<View id="Books" form="Book" sortBy="Title" sortOrder="asc">
  <Column id="Author" prominent="1"/>
  <Column id="Title" prominent="1"/>
  <ViewAccess groups="admin;member"/>

The prominent attribute tells the application that the column should be displayed using a bigger font in the list of records. The ViewAccess tag specifies the groups, whose members can see the view's records.

The records in a view appear sorted if the sortBy attribute is specified and refers to a data field of the corresponding form.