Artifacts

<<-- Short descriptions

This feature affects the functionality of the whole system. It is considered to be the most important feature of the system.

To enable the abstractness we want, we need to keep artifacts as simple as possible. At the same time, there must be a simple way to create a more complex artifact. The concept behind this is defined bellow. It does not reflect the implementation. If you are not familiar with UML you should jump directly to the Example.

Artifact concept UML Model

Bellow an explanation of the model.

Object	Field	Comment
Artifact	artifactId	Unique identifier
	parentId	Defines wether this artifact is a template or not. If parentId is NULL that means it is a template and should be cloned, otherwise it points to the template cloned to generate it.
	deleted	A flag marking this artifact as deleted.
	createdBy	The AraraUser who created the artifact.
	values	The AttributeValue values of this artifact. This can be any kind of information. If this is a template artifact these are the default values used when cloning it.
	attributes	These are the Attributes for the Artifact. For templates this defines the possible Attributes and for non-templates they are cloned from the template's attributes.
Attribute	attributeId	Unique identifier
	name	Name of the attribute (ie: Description, Status, Assigned To, ...)
	description	A description explaining what this attribute means
	createDate	Date when this attribute was created
	deleted	Flag marking this attribute as deleted or not
	permission	Name of permission related to this attribute
	requiredOptionId	A pointer to an option indicating that that is the required option for this attribute.
	artifact	The Artifact this Attribute belong to.
	createdBy	The AraraUser who created the attribute.
	value	Actual value of attribute.
	options	If this attribute's values are among a set of possible values, these values are defined by AttributeOption. (ie: pending, sovled, ...)
	attributeType	Defines the type of this attribute (ie: string, integer, Drop down list, ...)
AttributeType	attributeTypeId	Unique identifier
	name	Name of this type
	javaClassName	Name of the class that handles this type
	validationKey	Key for validation rule used for the value of an attribute of this type
	attributeClass	A more generic class that handles this attribute.
AttributeClass	attributeClassId	Unique identifier
	name	The name
	description	Description
	javaClassName	Name of the class that handles this type
AraraUser	userId	Unique identifier
AttributeValue	valueId	Unique identifier
	*	The other fields hold the possible values, depending on the type
AttributeOption	optionId	Unique identifier

This concept allows us to create several template artifacts that will be used as templates on the system. For instance, we could define an artifact for the Todo feature with the following attributes

• Owner - the user who owns it
• Expires - The date when this todo expires
• Status - Possible values for the status (not started | started | follow up | finished). The requiredOption would be finished.
• Involved - Users who are involved on this Todo

Notification

<<-- Short descriptions

Notification is a possible Attribute for Artifacts. It contains information about Contacts or AraraUsers who will be notified. It should also contain information about the type of Notification.

Concept UML for NotificationAttribute

This enable a pluggable architecture where we need to have a "plug-in" for every notificationType.

Users / Groups / Roles

<<-- Short descriptions

This feature is implemented base on Turbine's Core Schema. There is no point on re-inventing the wheel.

Datebook

<<-- Short descriptions

Datebook is a set of Artifacts derived of the same template. The template will have all attributes needed to enable a datebook feature. Some of them are:

• Owner - the user to whoom this Artifact belongs
• StartDate - A DateAttribute specifying when it starts
• EndDate - A DateAttribute specifying when it ends
• UserInvolved - Serveral UserAttributes with the users involved
• Notification - In case notification is required

One should note that other kinds of artifacts can be included on a datebook, like for instance a Todo Artifact could be displayed on the datebook on the day it expires.

Addressbook

<<-- Short descriptions

The addressbook is composed of several Contacts. These are basically ContactAttributes or UserAttributes.

The contacts should not be restricted to having only one contact. A group contact can be used to map a set of Users and Contacts together as one only Contact.

Todo

<<-- Short descriptions

These are Artifacts very similar to Datebook ones. The difference is that they have no StartDate, and they have several options for status. And could have dependencies on other Todo Artifacts.

Memo

<<-- Short descriptions

This is a very simple Artifact holding only text.

Expense

<<-- Short descriptions

These are Artifacts that hold information about money.

• Owner
• Currency - US$, R$, EURO, ...
• Type - expense, income, ...
• UserInvolved - Serveral UserAttributes with the users involved
• Notification - A notification about when a check is cached for example
• Amount

Documents / Attachments

<<-- Short descriptions

This is basically binary data, can also be an Attribute so that it can be added to other Artifacts.

Preferences

<<-- Short descriptions

Besides regular Preferences like

• Language
• User info - (email, name, ...)
• Preferred notification type
• ...

A set of Artifact templates (cloned from other templates) can be created by the user. This way it is possible, for example, for a user to define a template Datebook artifact. An example would be CompanyMeeting, with attributes like Notification, UserInvolved, ... pre-defined. This way every time a user wants to set up a CompanyMeeting, he can clone this template and fill in the gaps.

Export

<<-- Short descriptions

Exporting and importing is made pluggable because most information consists of Artifacts. Simply implementing an Export/Import utility that transforms Artifacts into the desired format and vise versa allows us to perform the task.

Misc

<<-- Short descriptions

Localization is acheived by using ResourceBundles for every language.

Pluggable emailing works because we can define an action to be taken whenever an email is to be sent/read passing the basic email information as parameters. All we need then is to create a "plug-in" that knows how to call the desired emailing application based on the available parameters.