In previous versions of mutual_credit, I went to great lengths to provide a 3rd party transaction form, a first party form which assumes one of the traders is the logged in user, and multiple transaction forms, in which multiple payers or payees could be specified. They should be completely malleable to user experience experts (who would surely pay a LOT of attention to a payment form). However it seemed that each new use case broadened the scope. So instead of producing one form per module, in v3 I'm attempting to produce a general transaction form building interface (see right). This is a first attempt, and I hope it will be useful. It has taken 3 weeks, but the first week was just getting Ctools to load and save.
Ctools, by the way is what the 'views' and 'panels' modules use to make the configuration objects exportable into code, which makes it easy to provide overridable defaults and to share webforms between sites. It means when you install the module, you have three overridable forms-in-code ready to use, just as views module comes with defaults. Then your forms can be exported into code to be included in Drupal 'features' configurations.
The intention of this module is to allow non-technical, or at least, non-drupal users the possibility to design and edit their own web forms in support of business rules and usability requirements.
Each webform has a menu callback (which is unique) and optionally produces a block. The widget for each of the transaction fields can be configured. This includes additional fields added to the transaction entity. The widgets are then replaced into an html template via simple tokens (simpler than Drupal 7 token system), so the themer can make the form look exactly as they want without touching php or editing template files on the server.
Instead of full workflow, each webform will edit transactions only in designated states, and will save the transaction in one given state, or unchanged. Further, the webform itself has access control (via the menu callback), and the currency access controls apply as well.
On top of this there are some interesting enhancements.
- Transactions are stored with the two user ids, i.e. from the perspective of a 3rd party, and the easiest way to make a transaction form is to enter the two parties directly. However a more usable option is provided which assumes that the logged in user is initiating the transaction, so the unknown factors are then who is the other participant and which direction is the trade in. Some use-cases only allow trade in one direction and it's on profile pages a block can infer the other user from the url, which means the transaction form can be mostly pre-filled. This was an essential feature in both previous versions of the module but this time around is done with much less code. See 'aspects' near the top of the form.
- The 3rd party transactions have an option to allow multiple payers/payees (but not both). The internal API doesn't actually support multiple transactions at the database level as validation can get complicated, so this option puts a wrapper around the form validation and submission which iterates through the transactions individually, which is plenty for now.
- I have created another module, called user_chooser which makes a form element which can be configured to show a dropdown or autocomplete field for selecting users of a given role or permission. The form can therefore be designed, say, to pay only gold star members.
- Confirmation page - if the second template is filled out, the transaction will not submit immediately but will give a second page intended for 'are you sure' purposes. The tokens in this case are not replaced by form widgets, but by text versions of the submitted form values
Ideally, transactions would have a customisable workflow, in which, like documents through a large organisation, they move from state to state through a business process via transitions performed by permitted users. There's a Drupal 6 module for this which works on nodes but no sign in v7. This might be an interesting alternative approach when workflow will surely be redesigned for entities, but could be overkill for community currencies.
These forms are not simply user interface candy, but intended to support different use cases. Some characteristics that some people would ascribe to the currency are here included in the forms. For example when CES allows only incoming transactions - that just means that those users can't see a form to allow them to do otherwise. What is emerging is I hope a highly configurable system which doesn't require php, html or Drupal knowledge to configure - although it helps to understand currencies!
Comments