Transcript VAW Overview - SourceForge

This guide contains overview
information that is useful if you
want to write reports or if you
need to extract information
from the API.
It is not ment as a developer
guide. Please check the
OpenACS manual for more
detailed information.
The ]po[ Data Model
Frank Bergmann, 2006-05-22
Payroll
HR
Skill
Database
Recruiting
Workflow
Application
Modules
Application
Services
Platform
Services
Web
Server
Project
Project &
Mgmt.
Subprojects
Project
Controlling
Timesheet
Mgmt.
Collaboration,
File
Calendar Content & KM
storage
Online
Wiki
Chat
Discussions
Mail Server WebDAV
Incident
Integration
Workflow
Content
Management
CMS
Blog
Full-Text
Search
Workflow
Engine
Reporting
Engine
Portal &
Components
Localization
Framework
OO
OO
Frame
Model
Object
Metadata
DynField
Object
Extensions
SOAP &
XML-RPC
DB-API
AOLServer
Search
Engine
TSearch2
Oracle Intermedia/Text
Database
PostgreSQL
Oracle 8i, 9i, 10g
Operating
System
Windows
+ CygWin
Linux
Solaris
Room
Reservation
ECommerce
BSD
Mac OS
Other
]po[
Overview
Surveys
Web-Mail
Finance
Finance
Base
Controlling
Quotes &
Invoice
Freelance
Invoicing
Payments
Timesheet
Financial
Invoicing
Reporting
Software
Package
Development
Manager
Profiling &
Templates
Performance
Debugging
Automatic
Automatic System
Testing
Software
Form
Updates
Builder
TCL
TransTranslation
lation
Workflow
TM
Integration
Automatic
Invoicing
Glossary
Available
Documentation
CRM
Contact
Mgmt.
Customer
Web Reg.
Marketing
Campaigns
CRM
Tracking
Mail Server
Integration
ISDN Tel
Integration
Security
OpenACS
Permission
Page
Basic
Contracts
Authentication
SQL
LDAP
Templates
Authentication
Automatic
Audits
Pound
Revers Proxy
BigBrother
Sys Mgmt.
Database
Replication
CVS
System
Mondrian
DataWarehouse
Postfix/
Sendmail
Finance
Guide
Translation
Workflow
Guide
Forum
Guide
Filestorage
Guide
Configuration
Guide
OpenACS
Developer
Guide
Operations
& Maint.
Guide
OpenACS
Inst. Guide
Unix Install
Guide
Contents







Other Documentation
General Conventions
"Categories"
]po[ Objects and Types
Main Classes
Financial Classes
Auxilary Tables
Other Documentation
This is a limited overview document.
For more detailed information please see:



]po[ Overview Diagram: http://www.project-open.org/
OpenACS Developer Guide: http://www.openacs.org/doc/
]po[ Whitepapers: http://www.project-open.com/whitepapers/

]po[ List of modules: http://www.projectopen.org/product/modules/
]po[ Developer Documentation: http://www.projectopen.org/doc/

General System Architecture

]po[ consists of three main parts:
– A powerful object-relational data model
– TCL pages that render the contents of the
database and
– TCL libraries that provide auxilary functions
to the TCL pages

The Data Model is particularly important in
]po[ because:
– It is object-oriented
– The TCL layer does not contain objects. It
merely renders the content of the Data Model
 The Data Model is the location where you
need to go if you want to extract information
from the system
TCL Pages
TCL Library
Data Model
General Conventions







Tables names are always in plural form and written in lower case
Tables are held in general in 2nd normal form
Denormalized table columns are named with a "_cache" postfix.
All main tables have an integer primary key <table_name>_id.
This primary key references the table acs_objects which
contains the type of the object.
Most object->object mappings are handleled by the "acs_rels"
table and its subclasses (see below). Other mapping tables are
called something_something_map
Boolean fields have a "_p" postfix and contain 't' or 'f' char
values
All main objects include "object_type_id" and "object_status_id"
fields. "Type" is used to create minor subclasses of the objects,
such as the distinction of im_companies such as "customer" and
"provider". "Status" is used to deal with the object's lifecycle,
such as "potential", "active", "closed" and "deleted".
Normal arrow
means referential
integrity relationship between
tables.
Big arrow tip means
inheritance relationship. An inheriting
"object" references
its parent class with
its object_id.
“Business Objects”
Data Model Overview – Business Objects

acs_objects
object_id
object_type
im_projects
project_id
project_name
project_nr
company_id
project_status_id
project_type_id
project_lead_id
supervisor_id
…

Most data in the ]po[ data model
are structured as “Business
Objects” (BizObj).
A “BizObj” is just a database table
following a number of conventions
– A integer primary key called
<object>_id representing a unique
object ID
– The primary key references the
“acs_objects” table. acs_objects
includes object meta-information
such as object type, creation date,
creation user etc.
– Every ]po[ BizObj includes a field
“object_status_id” re
Data Model Overview – Business Objects

acs_objects
object_id
object_type
im_projects
project_id
project_name
project_nr
company_id
project_status_id
project_type_id
project_lead_id
supervisor_id
…
acs_rels
rel_id
object_id_one
object_id_two

im_categories
category_id
category_type
name
description
The ]po[ data model is
based on the notion of
“Business Objects”
A “BizObj” is just a
database table following
a number of
conventions
–
–
persons
person_id
first_names
last_name
persons
person_id
first_names
last_name
–
A primary key
representing a unique
object identifier
The primary key
references the
“acs_objects” table.
acs_objects includes
object metainformation such as
object type, creation
date, creation user
etc.
Every ]po[ BizObj
includes a field
“object_status_id” re
Data Model Overview – Business Objects
 The ]po[ data model is based on the notion of
“Business Objects”
 A “BizObj” is just a database table following a
number of conventions
– A primary key representing a unique object identifier
– The primary key references the “acs_objects” table.
acs_objects includes object meta-information such as
object type, creation date, creation user etc.
– Every ]po[ BizObj includes a field “object_status_id” re
Hierarchical Queries
Main Project
Sub-Project 1
Sub-Project 1.1
Sub-Project 1.2
Sub-Project 2
Sub-Project 2.1
Sub-Project 2.2
"Categories"
object
Conventional/ traditional database design
normally includes a lot of foreign key
tables defining the type and status of an object.
]po[ takes a different approach in order to
minimize the number of database tables and
maintenance screens. We use a single
"im_categories" table for all types of status and
type information:
+ The total number of DB tables is reduced to
a third or fourth
+ A single maintenance screen is responsible
for managing categories.
+ Built-in features:
+
+
+
+
+
Localization
Hierarchical categories
Common GUI widgets
Referential Integrity is enforced
It is possible to assign the wrong Category to
a field
This has never happened in practice yet.
object_type
object_type_id
object_status_id
name
description
...
object_type_id
name
description
object_status
object_status_id
name
description
The "Classical" DB-Design: Every table has
it's own tables for type, status and similar
information.
object
im_categories
object_type_id
object_status_id
name
description
...
category_id
category_type
name
description
im_category_hierarchy
parent_category_id
child_category_id
]po[ DB-Design: All type and status information
is stored in a single "im_categories" table.
Categories
Sample SQL
Categories Definition
-- We use categories as a universal storage for business
-- object states and types, instead of a zillion of tables
-- like 'im_project_status' and 'im_project_type'.
create sequence im_categories_seq start 100000;
create table im_categories (
category_id
integer
constraint im_categories_pk
primary key,
category
varchar(50) not null,
category_description
varchar(4000),
category_type
varchar(50),
category_gif
varchar(100) default 'category',
enabled_p
char(1) default 't'
constraint im_enabled_p_ck
check(enabled_p in ('t','f')),
-- used to indicate "abstract"
-- super-categorys that are not
-- valid values for objects.
-- For example: "Translation
-- Project" is not a project_type,
-- but a class of project_types.
parent_only_p
char(1) default 'f'
constraint im_parent_only_p_ck
check(parent_only_p in ('t','f'))
);
Category Hierarchy
--------------
Optional system to put categories in a hierarchy.
This table stores the "transitive closure" of the
is-a relationship between categories in a kind of matrix.
Let's asume: B isa A and C isa B. So we'll store
the tupels (C,A), (C,B) and (B,A).
This structure is a very fast structure for asking:
Select Everything About Categories
select
c.*,
im_category_from_id(aux_int1) as aux_int1_cat,
im_category_from_id(aux_int2) as aux_int2_cat,
h.parent_id,
im_category_from_id(h.parent_id) as parent
from
im_categories c
left outer join im_category_hierarchy h
on (c.category_id = h.child_id)
where
c.category_type = 'Intranet Cost Types'
order by
category_type,
category_id;
Extract Categories Without Join
-- A helper functions to make our queries easier to read
create or replace function im_category_from_id (integer)
returns varchar as '
DECLARE
p_category_id
alias for $1;
v_category
varchar(50);
BEGIN
select category
into v_category
from im_categories
where category_id = p_category_id;
return v_category;
end;' language 'plpgsql';
-- Example:
-- select im_category_from_id(48);
"is category A a subcategory of B?"
but requires n^2 storage space in the worst case and
it's a mess retracting settings from the hierarchy.
We won't have very deep hierarchies, so storage complexity
is not going to be a problem.
create table im_category_hierarchy (
parent_id
integer
constraint im_parent_category_fk
references im_categories,
child_id
integer
constraint im_child_category_fk
references im_categories,
constraint category_hierarchy_un
unique (parent_id, child_id)
);
Create a New Category Entry
insert into im_categories (
category_id, category, category_type,
category_description, enabled_p,
aux_int1, aux_int2,
aux_string1, aux_string2
) values (
:category_id, :category, :category_type,
:category_description, :enabled_p,
:aux_int1, :aux_int2,
:aux_string1, :aux_string2
);
]po[ Objects and Types
All major ]po[ tables are "Objects"


Objects are identified by an object_id.
Information about object type is stored in the
acs_objects table, together with metadata and
creation information.
Advantages of "being" an object:





Permission system:
Associates objects with "privileges", including all
necessary maintenance screens
SQL metadata system:
Allows the administrators to dynamically extend
object types with new attributes
Full-Text search:
Indexes all objects and produces generic URL for the
search results
Configurable workflow:
Allows to manage the status of any object. The WF
includes a graphical WF editor.
Generic Object Relations:
acs_rels allows you to define generic relationships
between objects.
acs_attributes
attribute_id
pretty_name
object_type
table_name
column_name
acs_object_types
object_type
supertype
table_name
id_column
name_method
acs_objects
object_id
object_type
object
object_type_id
object_status_id
name
description
...
]po[ Objects and Types

acs_attributes:
– Each row in acs_attributes table defines an attribute of the specified object
type.
– The contents of the table is managed by the "intranet-dynfield" package that
contains a SQL metadata editor.

acs_privileges:
– Contains permissions "tokens" (=> privileges). These privileges allow a user to
perform a certain operation in the system.

acs_permissions:
– Defines a mapping between acs_objects and acs_privileges.
– The mapping is per user group ("grantee_id"). Groups can be hierarchical.
acs_objects
Main Classes
object_id
object_type
acs_rels
rel_id
object_id_one
object_id_two
groups
parties
group_id
group_name
party_id
email
url
im_profiles
profile_id
profile_gif
im_companies
company_id
company_name
company_status_id
company_type_id
main_office_id
primary_contact_id
accounting_contact_id
vat_number
note
im_biz_objects
object_id
im_offices
office_id
company_id
office_status_id
office_type_id
<Address>
persons
person_id
first_names
last_name
im_projects
project_id
project_name
project_nr
project_path
customer_id
project_status_id
project_type_id
project_lead_id
supervisor_id
project_budget
budget_currency
budget_hours
start_date
end_date
description
note
users
user_id
username
password
salt
auth_token
users_contact
<Home Address>
<Work Address>
im_employees
<Payroll Info>
<Recruiting Info>
im_freelancers
<Freelance Info>
Main Classes

im_biz_objects:
– This abstract class defines a number of functions to manage "horizonal
permissions" (=> Please see other ]po[ documentation) for project, companies
and offices
– "Horizonal" permissions currently include roles such as "Project Manager" of
"Full Member".

parties, persons, users:
– These three tables form an inheritance hierarchy. There is a view "cc_users"
that unifies the information from these tables.

im_freelancers, im_employees, users_contact:
– These are "extension tables" for "persons" and define additional information for
users with particular profiles.

im_profiles:
– This table defines the groups that are relevant for ]po[, as opposed to
potentially hundereds of groups of the underlying OpenACS system.
acs_objects
Financial Classes
object_id
object_type
Inheritance!
im_invoices
invoice_id
company_contact_id
invoice_nr
invoice_office_id
im_invoice_items
item_id
item_name
project_id
invoice_id
item_units
item_uom_id
price_per_unit
currency
sort_order
item_type_id
item_status_id
description
im_costs
im_payments
cost_id
cost_name
cost_nr
cost_status_id
cost_type_id
payment_id
cost_id
company_id
provider_id
received_date
payment_type_id
payment_status_id
amount
currency
note
project_id
customer_id
provider_id
cost_center_id
investment_id
template_id
effective_date_id
payment_days
amount
currency
paid_amount
paid_currency
tax
vat
description
note
Cost Types
All costs have an entry in
im_costs, plus:

–
–
–
–
–
im_cost_centers
cost_center_id
cost_center_name
cost_center_code
cost_center_type_id
cost_center_status_id
department_p

im_expenses

expense_id
ext._company_name
ext._comp._vat_num.
billable_p
reimbursable
bundle_id
Financial Docs
(im_invoices)
Customer Invoice
Quote
Provider Bill
Purchase Order
Delivery Note
Simple Costs
(only im_cost)
– Timesheet Cost
– Employee Salary

Expense Item
(im_expenses)
Expense Bundle
(im_expense_bundles)
Financial Classes (2)
acs_rels
rel_id
object_id_one
object_id_two
Relationship between Costs and Projects
im_projects
project_id
…
im_costs
cost_id
cost_name
cost_nr
…
project_id
select distinct
c.cost_name,
im_category_from_id(c.cost_type_id) as cost_type,
c.amount * im_exchange_rate(c.effective_date::date,
c.currency, 'EUR') as amount_converted
from
im_projects main_p,
im_projects sub_p,
acs_rels r,
im_costs c
where
main_p.project_id = :main_project_id and
sub_p.tree_sortkey between main_p.tree_sortkey and
tree_right(main_p.tree_sortkey) and
r.object_id_one = sub_p.project_id and
r.object_id_two = c.cost_id
A sample query to extract all financial items
related to a certain main-project.
The Problem:
Cost and Projects can have a N:M relationship:

One project may have more then one invoice/cost item.

One cost item may “relate” to more then one project (in particular: project + sub-project, but also
the item may be split between two main projects).

An invoice may actually not belong to any project at all.
Solution:

In general, the relationship between projects and costs is defined as an N:M relationship by
acs_rel.

im_costs.project_id points to im_projects ONLY in the case that one cost item relates to exactly
one project
Watch out:

Cost Items can be related to a main-project or to a sub-project or any level. So in order to
calculate the main project’s total Profit & Loss, you need to sum up the financial items through the
full project tree (hierarchical query)
Financial Classes (3)
Main project
Example
im_projects
project_id
…
Sub-project
with cost item
im_projects
project_id
parent_id
…
acs_rels
rel_id
object_id_one
object_id_two
im_costs
cost_id
cost_name
cost_nr
…
project_id
im_projects
project_id
parent_id
…
Sub-project
with cost item
Financial Classes

im_costs:
– This is the main table for all cost items.
– All financial elements in the system are stored in this table.
The table also receives updates from timesheet (cost related
to users working on a project) etc.

im_cost_centers:
– Is currently not used. The table has been included in the
current datamodel for smooth upgrade in future versions.

im_invoices:
– This table contains financial documents such as "Invoices",
"Quotes", "Bills" and "Purchase Orders" (the name
"im_invoices" is a bit misleading).

im_invoice_items:
– These are the individual lines of an invoice.
acs_objects
Relationship Classes
object_id
object_type
acs_rel_type
rel_type
object_type_one
object_type_two
role_one
role_two
acs_rels
rel_id
rel_type
object_id_one
object_id_two
membership_rels
rel_id
member_state
composition_rels
rel_id
min_n_rels_one
max_n_rels_one
min_n_rels_two
max_n_rels_two
admin_rels
rel_id
group_rels
rel_id
rel_type
group_id
im_biz_object_members
rel_id
object_role_id
Defines the relationships between an
im_biz_object and some users. The membership
type corresponds to "horizontal permissions" and
usually includes "full member", "project manager",
"key account" and user-defined roles.
Relationship Classes

acs-rels:
The acs_rels table is essentially a generic mapping table for acs_objects. Once we
come up with a way to associate attributes with relationship types, we could
replace many of the ACS 3.x mapping tables like user_content_map,
user_group_map, and user_group_type_modules_map with this one table. Much
application logic consists of asking questions like "Does object X have a relationship
of type Y to object Z?" where all that differs is X, Y, and Z. Thus, the value of
consolidating many mapping tables into one is that we can provide a generic API
for defining and querying relationships. In addition, we may need to design a way
to enable "type_specific" storage for relationships (i.e., foreign key columns for
one-to-many relationships and custom mapping tables for many-to-many
relationships), instead of only supporting "generic" storage in the acs_rels table.
This would parallel what we do with acs_attributes.

im_biz_object_members:
– Defines the member of a im_biz_object and their roles (project
manager of full member).
– Such a membership has an impact on the access rights of members
to the business object.

membership_rels: Defines group->supergroup relations
acs_objects
object_id
object_type
im_costs
im_invoices
im_trans_invoices
im_trans_tasks
task_id
task_name
task_filename
task_status_id
project_id
task_type_id
source_language_id
target_language_id
subject_area_id
task_uom_id
invoice_id
quote_id
end_date
task_units
billable_units
im_trans_trados_matrix
object_id
match_x
match_rep
match_100
match_95
match_85
match_75
match_50
match_0
Translation Classes
trans_id
edit_id
proof_id
other_id
match_x
match_rep
match_100
match_95
match_85
match_75
match_50
match_0
note
im_trans_prices
price_id
company_id
task_type_id
source_lang_id
target_lang_id
subject_area_id
uom_id
currency
price
note
im_trans_quality_reports
report_id
task_id
report_date
reviewer_id
sample_size
allowed_errors
total_errors
comments
im_trans_quality_entries
report_id
quality_category_id
minor_errors
major_errors
critical_errors
Translation Classes

im_trans_tasks:
– This tables contains the description of the main activity related to translation
projects.
– Includes information about Translation Memory repetitions
– Inludes information about the translator, editor, proof-reader and "other"
assigned to perform this task (static workflow)

im_trans_invoices:
– This is currently just a flag (binary information) to identify invoices that have
been created based on im_trans_tasks. Translation invoices are referenced by
im_trans_tasks.invoice_id in order to make sure that every trans_task is
included in exactly one invoice. These references need to be removed if a
translation invoice is deleted.

im_trados_matrix:
– Contains the discounts per customer and translation task type for different
Translation Memory matches.
– The trados_matrix associated with the "internal" company contains the sitewide defaults for customer translation prices.
acs_objects
Timesheet Classes
object_id
object_type
im_costs
im_invoices
im_projects
project_id
project_name
customer_id
project_type_id
start_date
end_date
im_ts_invoices
...
im_timesheet_tasks
im_materials
material_id
material_name
material_nr
material_type_id
material_status_id
material_uom_id
description
task_id
material_id
uom_id
planned_units
billable_units
cost_center_id
invoice_id
priority
im_timesheet_prices
price_id
company_id
task_type_id
material_id
uom_id
currency
price
note
im_ts_task_deps.
task_id_one
task_id_two
dependency_type_id
difference
hardness_type_id
Consulting Classes

im_timesheet_tasks:
– This tables contains the description of the main activity related to projects.

im_timesheet_invoices:
– This is currently just a flag (binary information) to identify invoices that have
been created based on im_timesheet_tasks. Timesheet invoices are referenced
by im_timesheet_tasks.invoice_id in order to make sure that every task is
included in exactly one invoice. These references need to be removed if a
timesheet invoice is deleted.

im_timesheet_prices:
– Contains a price per material and customer.
– The timesheet_prices associated with the "internal" company contains the sitewide default price list.
Workflow
Workflow



]po[ uses a Petri-Net based workflow
A workflow consists of “Places”
(states) and “Transitions”, linked by
“Arcs” that might carry “Guard”
expressions.
WF “Transitions” can be linked to
pages acting on object’s fields
Workflow
StartPlace
Transition
Place
Place
Transition
[Guard]
[Guard]
EndPlace
WF @ Runtime

During runtime, a similar structure is
created representing a specific “Case”
(a specific instance of a WF):
– The “case” corresponds to a WF in
action.
– Transitions become “tasks”, with
specific assignments to users.
– Places may include “tokens” that
move through transitions to other
places. A single token in a WF place
can be thought as “the WF is in status
XXX”.

Case
Petri-Nets allow for more then one
token and more then one token per
place, but this option is rarely used in
]po[.
StartPlace
Task
Place
Place
Task
[Guard]
[Guard]
EndPlace
WF Tables
Static
Assignments
Workflow
wf_workflows
workflow_key
wf_roles
role_key
workflow_key
wf_transitions
transition_key
workflow_key
role_key
direction
wf_places
place_key
workflow_key
wf_arcs
transition_key
place_key
direction
Case
wf_cases
case_id
workflow_key
object_id
state
wf_tasks
task_id
case_id
transition_key
state
wf_tokens
token_id
case_id
place_key
state
WF “Callbacks”
“Callbacks” are Pl/SQL database
procedures that determine the behavior
of a transition:
 A number of “Outgoing Events” allow
to customize the behavior of WF
transitions:
– Enable: Is called when the transition is
enabled (a token is placed in one of its
input places)
– Unassigned: Is called if the transition
hasn’t been statically (see below)
assigned to a user or a group.
– Fire: Is called once the transition gets
fired

A number of transition’s parameters
can be determined by external
routines:
–
–
–
–
Time:
Deadline:
Hold Timeout
Notification
Transition
States
“Enable”
“Unassigned”
Enable
Enabled
“Fire”
Time
Start
Started
Deadline
Hold Timeout
Finish
Cancel
Notification
Finished
“Fire”
<autom>
Can
celed
WF Assignments

“Static Assignments”:
–
–
–
–
–

Transition
States
Specified during the definition of the WF
Specified using WF “roles”. Each role can be
assigned to one or multiple parties (groups or
users)
Specified as “roles” using
wf_transition.role_key and then mapped to
parties using wf_context_assignments.
The specific assignments at runtime are held
in wf_task_assignments.
This construction might seem a bit complex,
but it is necessary, as you will find out when
defining your first real WFs.
“Dynamic Assignments”
–
–
–
Use the “Unassigned” callback to define the
assigned parties.
This option allows you to specify the assignee
as a function of object characteristics etc.
The results of dynamic assignments are
stored in wf_task_assignments.
Enable
Enabled
Start
Started
Finish
Cancel
Finished
<autom>
Can
celed
Timesheet &
Controlling
Timesheet & Controlling
Requirements and Architecture
 Controlling uses caches per project in order to
maintain aggregated Profit & Loss (P&L)
information.
 The project caches are updated via triggers
 Reporting on portfolios & customers is handled
by the reporting engine.
Customer
Group
Customer
“Backward” Reporting
Values are summarized via Reports
Main
Project
Sub
Project
“Timesheet”
Task
“Forward” Propagation
Costs are cached. Caches are updated via triggers
Timesheet & Controlling
Controlling cache architecture



Projects contain a set of “xxx_cache”
fields that contain the aggregated cost
elements per type.
CUD (create, update, delete) operations
on costs (timesheet hours, expenses, …)
does NOT update the caches, for
performance reasons. Instead,
“Sweeper”
triggers reset the
Process
“cost_cache_dirty” to NULL.
There is a “sweeper” process that
periodically checks “cost_cache_dirty” and
updates the cache. This might be a
nightly activity, or every few minutes.
im_projects
project_id
…
cost_quotes_cache
cost_invoices_cache
cost_timesheet_planned_cache
cost_purchase_orders_cache
cost_bills_cache
cost_timesheet_logged_cache
cost_expense_planned_cache
cost_expense_logged_cache
cost_delivery_notes_cache
reported_hours_cache
cost_cache_dirty
Timesheet & Controlling
The hours are
aggregated from
tasks up to main
projects
Controlling cache architecture
Project
im_hours
user_id
project_id
day
reported cost_ts cache
hours
logged _dirty
(9)
(4)
4
Main Project
Sub Project1
Task1.1
Task1.2
SubProject2
Task2.1
Task2.2
(5)
3
2
hours
billing_rate
billing_currrency
note
conf_project_id
refers to the main
project. All sub
projects and tasks
are included.
im_costs
cost_id
conf_object_id
cost_id
…
im_ts_conf_objects
conf_id
between
conf_project_id
conf_user_id
start_date
end_date
conf_status_id
conf_type_id
Auxiliary Tables
Auxilary Tables
im_component_plugins
GUI

Define what "plugins" (these grey boxes) should appear
on what page
Menu

Defines the hierarchical menu structure of the system
ViewColumn

Define the columns for ListPages in the "core". The
ListPages need to be extensible at runtime because they
might have to accomodate new columns from add-on
modules
Country

The list of all countries in the world
Currency

The list of all currencies
view
View
Auxilary Tables
im_component_plugins
GUI

Define what "plugins" (these grey boxes) should appear
on what page
Menu

Defines the hierarchical menu structure of the system
ViewColumn

Define the columns for ListPages in the "core". The
ListPages need to be extensible at runtime because they
might have to accomodate new columns from add-on
modules
Country

The list of all countries in the world
Currency

The list of all currencies
view
View
Frank Bergmann
[email protected]
www.project-open.com