Prefilled, Cached Form "Templates"

[jniles]

This issue describes a method of manually saving the form values for almost any form in a local cache, to be loaded easily at a later time.

Motivation

There are some large forms in bhima may be used a lot. For example, the Journal Voucher form and Simple Voucher forms will take over the entire function of the outdated "Primary Cash" module in bhima. Many of these transactions will be very similar:

1. "Receive X amount into the cashbox for reason Z"
2. "Disperse Y amount from the cashbox for reason M"

Since we have a robust cache system in bhima, we could allow the user to saved named "templates" of transactions that happen frequently. The user would be able to load this template up by its name, fill in a few details, and submit to the database.

Mockups (Simple Voucher Example)

Template Buttons on a Form

Loading a Previous Template

Saving a New Template

Previous Template Selected and Loaded

Design

The mockups should do a pretty good job conveying the design. The form controller would import the FormTemplateLocalCache service, and assign a namespace to save the forms under locally. If there are templates available, it will display the "Load a Template" link. Otherwise, this button will be hidden.

Not all information should be cached! The date, amount, user, etc... should not be saved. The design of the "Save a Template" modal will need to take this into account.

The "Load a Template" modal will likely be generic (simple a call to FormTemplateLocalCache.loadTemplate(namespace)), but the design of the FormTemplateLocalCache.saveTemplate(namespace, data) will likely need to be specific to the form, in order to know what to cache and what to discard. It also needs to show a specific preview, depending on the form it is called from.

Additional Thoughts

If this is a useful concept, we might think about developing a way to store the vouchers on the server-side. For now, we should limit our scope to the client until we have proven that this idea is a useful feature.

[sfount]

This looks like a very useful feature - especially for journal vouchers/ simplified journal vouchers. I would guard against spending a lot of time making this 100% generic/ flexible for now as we are approaching a development deadline but this would make these two pages extremely polished.

Initially I thought you were describing a generic form cache utility that recovers an object (with ng-models attached) if the page had not completed submission on a form (similar to the cache in patient invoices - and how GithHub will save your comments/ pull request text if you close the browser/refresh the page). The library/ service could be attached to a form so that each page does not have to implement this cache logic individually. I don't think this suggestion is very high priority but if anyone thinks it is interested we can create an issue tracking it.

(Really slick mock ups!)

[jniles]

@sfount , thanks for your feedback.

Yes, the #207 issue mentions something similar to the cache utility you are describing (in the advanced features). We should definitely create an issue tracking that, though I agree it is pretty far off at this point. Once we have a few more form examples working, we'll feel a much greater use for such a cache.

Just in case anyone is confused about the difference between the two methods of caching, here is a breakdown of key differences:

This Proposal

1. selectable, named form records (called "templates" here)
2. stores any number of templates
3. cache is manually created by a user, whenever they feel the need

@sfount's Proposal

1. automatic caching
2. stores only one cached form at a time (per namespace)
3. caching is automatically created and removed.

[jniles]

This is pretty close to superseded by Voucher Tools introduced to the Simple Voucher module. Closing as it will need to be re-evaluated to implement in the current application's ecosystem.