18.0 Customizing Objects

Moab Accounting Manager provides the ability to dynamically create new objects or customize or delete existing objects through the interactive control program (goldsh).

Note The object customizations described in this chapter will be noticeable in subsequent goldsh queries (and in the web GUI after a fresh login). For installations with a database that supports multiple connections (e.g. PostgreSQL) these changes will be visible immediately while others (e.g. SQLite) will require the server to be restarted. Client commands may need to be modified to properly interact with changed objects or attributes.
Note The goldsh control program allows you to make powerful and sweeping modifications to many objects with a single command. Inadvertent mistakes could result in modifications that are very difficult to reverse.

18.1 Managing Objects

In Moab Accounting Manager, Objects correspond to tables in the repository which have Attributes (such as Name and Color) and Actions (such as Query and Modify). A specific instance of an object is described as an Instance and has Properties (the specific values of the attributes for that object). The instance is uniquely referred to via its primary key(s) (such as its Name or Id).

An object must have a name and may have a description. An object may be set to auto-generate its instances when first seen (see Object Auto-Generation) and/or a default value may be designated for the object (see Object Default Values).

Objects may reference other objects. If a single instance of an object references only a single instance of another object (for example, a usage record may only have one user), then it is sufficient for the first object to have an attribute field for the second object (the UsageRecord object has an attribute called User). However, if there may be a many-to-many relationship between objects (for example, a project may have multiple users and a user may belong to multiple projects), then it is necessary to maintain a separate object as an association table (i.e. ProjectUser). When creating an association object, the object should be given an appropriate name (i.e. ProjectUser), it should be marked as an association (Association=True), and an object needs to be designated for the parent (i.e. Project) and the child (i.e. User). The association object itself may have additional attributes that provide qualitative information about the association (i.e. a particular ProjectUser association may be active or be an administrator).

(Undefined variable: MyVariables.!CopyrightInfo!)