About FirstClass application development An application is a collection of: •       custom forms, created using FirstClass Designer •       mail rules and application rules •       custom columns and view properties       •       FirstClass scripting The above elements can reside in a container or in a container template. •       User groups Users are given access to an application through a conference or folder. Use model Desktops to give group members access to the application container. How to begin building an application The first step in creating an application is to figure out exactly what you want the application to do and how it will work. The planning and development of a FirstClass application requires a deep understanding of FirstClass features and philosophy. Once you have planned your application and you know what all the required components are and how to implement them, you need to create a new application using FirstClass scripting. The INITIATEAPPINSTALL command registers FirstClass applications in the Application Configuration form and creates the application folder. If the application registration fails, the script terminates. At startup, the console will list all Registered applications by name and registration number. The console will also display a message about the application when a new application is created or uninstalled. FirstClass components used in application development As mentioned above, an application is built using existing FirstClass features and components. This section gives a brief overview of how they are used in application developments with links to full feature documentation. Container Templates A Container Template controls member containers': •       permissions •       custom columns •       toolbars •       view properties (layout) •       explorer options •       resources •       rules Related links About container templates Using container templates The container template permissions form Custom columns Custom columns allow the administrator or application developer to add new columns to the container, or to entirely replace the default columns. Columns can be propagated with a variety of information from text, images, or icons, to a checkbox field from a form. Users can be given the privilege of customizing their container view, or having it unalterable from what is set on the custom columns form. Related links Creating custom column layouts Custom columns form help Customized toolbars Custom toolbars can be set at the container template level. In addition, manual rules can be placed on the toolbar, making it easy for anyone with appropriate permissions to run the rule, without requiring permission to open the Rules folder in the container. Related links About container templates Customize toolbars form help Alternate container views Container templates allow you to specify the container layout to use based on the user's permissions. Moderators can be given an entirely different conference view than users, including alternate column layout, toolbar objects, backgrounds, etc. Example The Class and all the subcontainers are in two groups. Teachers are moderators, so they inherit the Moderator views. They see a custom column to approve conference items, they see all standard columns, they have manual rules on their toolbar, and their view is less cluttered with images. Students are Contributors or less, so they inherit the Default view, which includes a simpler interface with fewer columns, and exciting background images. Related links Alternate moderator views Container template form help Locking container views for users 8.0 AP introduced the following enhancements, available at the container template and individual container levels. Use view from server Required if the member container requires custom columns or custom toolbars Use template view only Useful when using both the Alternate & Default views. Users will not be able to customize their views of member containers.         Note Once checked, these feature is always enabled. If a container is a member of a group where feature is enabled through a checkbox, then the feature is on, there's no way to switch is off. Another group may be required. Related links Container template permissions form help Using unapproved items Unapproved items can be hidden from the list view of a conference, viewable only by the conference moderator. To enable this feature, select "Hide unapproved items" on the conference permissions form. Using custom columns and alternate views, the moderator can simply click a hidden "approval column" from the moderator's container list view to instantly approve the message. There is no need to open the properties form. Related links Conference permissions form help Creating containers that will not be listed in the Directory Unpublished conferences do not appear in the Directory, even the administrator's Directory. For this reason, mail cannot be addressed to unpublished conferences, but mail to the conference may be created by clicking the New Message icon or selecting Message > New Message from within the conference. Because they are not in the Directory, there are no duplicate name conflicts associated with unpublished conferences. Once enabled, any container that is made a member, will not appear in the Directory. This applies to newly created containers added to the container template only. Related links About shared containers Working with shared containers Container template permissions form help Conference permissions form help Rules & Resources Rules and resources are available at the container template level, to be used by all member containers. To open the Rules & Resources folder 1       Open the container template. 2       Click Resources. The application rule Application rules give access to an expanded set of triggers, conditions, paths, and actions. Creating Application rules requires the Application Developer privilege, set on the Group Privileges or User Info form. From the Rules folder, click the New Application Rule icon: New triggers Message vs Item A message is a leaf item delivered through the MTA. Item Modified Rule runs only if the something is modified, the rule runs on close. Message Read This trigger occurs when an object is opened, at the end of the fill. It is most useful when used with the client field masking action (Set field / Send to Client). Manual Manual rules can now be placed on a toolbar, and you can control when to toolbar icon will be available for use. New Paths Path syntax for direct access to specific containers:         {Desktop}       Current user's desktop         {Mailbox}       Current user's mailbox         {Calendar}      Current user's calendar         {Contacts}      Current user's contacts folder         {Typed=##}      Current user's typed folder, Contacts (7), My Documents (32) for example         {AppID=####}    Root folder of application with ID #### At the group level, the path entered must be relative to the application folder, or start with ! in order to evaluate the path when the rule is executed by the user. Conditions of note Transfer Field Used to copy field content from either a form or the schema. Could be used to auto number assignments. Get Confirmation Used to get input from the user. Could be used to create classes and modules. Open Picker Used to open a container, usually relative the administrator's Desktop.         Get Confirmation/Open Picker notes These actions can occur anywhere in the action list and there can be multiple occurrences of either. They can also occur in any order. This means that a rule can perform some actions, be interrupted, and then continue processing after the confirmation or picker window has been accepted. Closing the window stops rule execution. Any fields collected by any of the actions will be retained and available to any subsequent actions. For example, if a field is entered on an earlier form by the user, and the same field ID appears on a later form, the user's input will be displayed in the later form. Some rules actions affect the later processing of other actions. You should avoid splitting these sets of actions across an Open Picker or Get Confirmation action, since these currently reset the action processor. The best way to avoid problems is to perform the user interface actions first and finish with the actions which perform operations on the store. Related links Application rule form help Forms and special field IDs Field Control The Field control field tells FirstClass to perform a particular action on another field, depending on the value chosen in this field. This field applies to checkboxes, numbers, radio groups, and static lists. The value the user chooses in one of these fields controls the value in, or state of, the controlled field. For example, the chosen value can: •       select (1) or clear (0) another radio button •       select (1) or clear (0) another checkbox, or set that checkbox to the third, unchanged, state (2) •       set the number in another field •       choose a list item in another field •       show (S) or hide (H) another field •       enable (E) or disable (D) another field •       protect (P) or unprotect (U) another field.         Note Field control doesn't take effect until users make choices. Therefore, you must make sure that fields appear the way you want them to when users first open the form. Examples Approve/Unapprove field (61) If a form has a field 61, where the value can be set to either 0 or 1, the field can control the approve/unapprove state. Editor Field (43) A editable field with the ID of 43 will have a fully functioning editor field. Useful in tabbed form. Field 30002 & Get confirmation forms. The Get Confirmation rule, can also optionally specify some text, which appears as field 30002 on the form. This can be used for any purpose, for example to allow a single form to be re-used, by using field 30002 as the guide text. Open Picker forms must be in the 7900 - 11000 range. The 30002 field can also be used on your picker forms. Related links FirstClass Designer - Making one field control another FirstClass Scripting Rules & Scripting Rules support an action to run batch admin. If a rule is created with this action it will only compile if the current user is the administrator. Users will be able to run the script, most likely by choosing a manual rule, but they can only perform actions that they are allowed to do through the client. The commands can be contained directory in a the rule action, or can use the EXECUTE command to access a script. The EXECUTE command provides more flexibility and expendability. Session data Running batch admin command from a rule action also gives you access to session data for field substitution. 7001    User's first name 7002    User's initials 7003    User's last name 7006    User's Client ID 7012    User ID 7100    User's full formatted name 7101    Date of copy 7102    Time of copy 7103    Selected item 5004    User's primary OU Example The ENABLEFIELDSUBSTITUTION FirstClass scripting command help includes a detailed example of how this feature can be used. Related links FirstClass scripting - ENABLEFIELDSUBSTITUTION command FirstClass scripting - EXECUTE command Adding the AppID to the application An application must have an AppID. When the INITIATEAPPINSTALL FirstClass scripting command is run, the application containers is automatically defined as an Application Container subtype (35). To configure the AppID, you need to use the FirstClass scripting PUT command. The PUT command help includes an example that can be used to configure the AppID. Add Person command The client supports a new command "Add Person" which can be accessed using a toolbar button. This opens a Directory window from which you can select one or more names. When the users' names are selected, the server adds a subscription to the parent container. This way, users with the "Edit permissions" conference permission can add user subscriptions without being given permission to open, view, or edit the container permissions form. The Add Person command will create a folder in the parent container called "Roster". The name of this folder can be changed at any time. A list of users who have access to the parent container is captured in the Members list. To add the command to the toolbar: 1       Choose View > Toolbars > Customize Toolbars 2       Choose Collaborate at Category. 3       Drag the Add Person icon to the toolbar. When using Add Person, if the container has the "Requires messages to be approved" permission enabled at the container or group level, the user is added unapproved.