Forum OpenACS Q&A: Form Builder Package

Collapse
Posted by Nitish Bezzala on
Hi,

I would like to implement a package to manage forms in companies.

I thought it could be modelled on the survey package, and I am trying to understand a few things.

Can anyone please explain why the survey package does not use the content repository.

If the survey package were to be redesigned with versioning of surveys in mind, would it use the content repository?

Thanks,
Nitish

Form Builder Package Requirements

The Big Idea

Employees of our company spend a lot of time filling forms, signing them and submitting them to different departments, which then spend time processing them.

The Form Builder aims to automate form creation, form filling and form submission.

The security and permission system will ensure that signing of the forms by hand is not necessary any more.

User Scenarios

Employee

Joe user wants to buy a book. Currently, he needs to download the proposal sheet from the portal, fill it and get it signed by his manager and the BUH. Then he submits it to the finance department which signs it and raises a purchase order.

If the new form builder pakcage is installed-

He logs into the portal, clicks on form builder module, clicks on the proposal form.
He fills in all the details including description, amount etc.
He now has three more fields to fill –
Recommended, for which he chooses his manager
Concurred – he chooses the BUH
Approved - he selects the finance department.

When he clicks the submit button, an email is sent to the manager for recommendation. The manager logs in to the portal and accesses the form. He can edit any field in the form and then click on accept or reject.

If the manager accepts the form a mail is sent to the BUH where the process repeats. Once the manager accepts the form, the user can no longer edit it.

If the Business Unit Head accepts the form, it goes for approval to the finance department.
The finance department can put in their comments and accept or reject the proposal.

The finance department will now have to fill in the purchase order form. They have the option of getting the values from the proposal form. The values should be of the same type and must have been mapped earlier.

This then starts the process again for the new purchase form.

Emails are sent to the form submitter at every step to keep him informed of the progress.
All dates and times of form submission and acceptance are logged in the database.

Admin

Jane admin has the permissions to create new forms.
She logs into the portal, clicks on form builder, and then ‘New Form’.

If the form needs input from an already existing form, she can select from a list of existing forms.

To create the first field in the form, she enters the field name (eg: Description, Amount) and chooses the presentation type (text box, check box etc). Depending on the presentation type, the user is given options. For a text box, she gets to choose the field type as text or number. For check boxes, she can create a list of choices.
She then optionally chooses a field in the existing form which maps with the Description in this form.

Similarly the other fields are created.

She can create text areas, check boxes, radio buttons and list boxes.
Then she selects the recommended, concurred and approved check boxes as this form needs three levels of approvals and hits submit.

Next, she sees a groups and permissions page, where she chooses an admin for the form, the group which owns the form, and the group of users who have access to read and to fill in the form.

Requirements

Non programmers should be able to generate forms.
Users should be able to find forms easily.
The forms should be categorized into different departments.
Only the departments concerned should be able to view the filled forms.

Reports generated

Forms filled in by a user
Forms waiting for approval from a user
Forms approved by a user
Forms status reports
Service level reports by department.

Possible Enhancements

Field wise permissions – Only the manager can fill in certain fields in the form.
Show or hide fields depending on whether it is an employee or manager.
Add support to submit forms to other websites.
Versioned forms
Admin can reorder the form fields.
Reports based on selected fields in the forms.
Rendering of the files in pdf or other formats, using templates associated with the forms.

Collapse
2: Re: Form Builder Package (response to 1)
Posted by Nima Mazloumi on
Hi Nitish,

here some thoughts:

- don't call it form builder package since "form builder" is used to describe the part in the templating system that creates forms for OpenACS

- your whole idea sounds like a little workflow. you can check bug-tracker on how workflow might be useful, though there is no support for field specific permissions but workflow does all the magic of notifications, opening/closing/commenting/...
The only problem with bug-tracker is, that once a ticket is defined (the fields of an object) it cannot be extended. So right now you would have to created several instances for each form (book suggestion, purchase order...).

- see also package assessement/tcl/as-action-proc.tcl for how they extended assessment to allow the definition of actions that take place when an activity has taken place. By the way, assessment is the successor of survey.

Greetings,
Nima

Collapse
3: Re: Form Builder Package (response to 1)
Posted by Dave Bauer on
You definitely should look at the assessment package. I think it covers many of your requirements.

It does not support permissionsing per field, but that should be possible as "questions" in an assessment are objects. Assessment is based on the content repository.

I suggest looking where assessment meets your needs and trying to figure out which features can be added to the assessment package and which should belong in a seperate package. It is possible that assessment would be used to design and manage the forms for an administrator and you might need to build a new public user interface for users to find and fill out the forms.