Notice to non-developers: This post is about how some functionality in 4.2 will be implemented in code and in the database, with very minor changes to anything visible through a browser. If you're not a developer, it probably won't interest you.
Simplifying the Codebase
As part of the CiviAccounts project we are looking to redo some of the implementation of the configuration and processing of payments for contributions, memberships, and events. Currently the processing for each of these three types of objects has two paths: one for a simple configuration of the objects, and one using price sets. This means there is more code, more complexity, more possibility of errors, more work when making changes, and more need for testing.
As we refactor the existing code we're looking at keeping the simplified UI for configuration and administration, but implementing everything under the hood using price sets. Before going ahead with that, we wanted some feedback from developers in the community.
Price sets are now supported for contributions, events, and memberships. You can use them to sell individual or multiple tickets at a time, items along with memberships and subscriptions, or allow contributors to determine how much to give / buy using text/numeric fields, select widgets, radio buttons, or checkboxes. Support for contributions on the same form the same as ticket purchases, and for contributions along with membership purchases is facilitated with price sets. They will be a good way to implement a page that allows people to get a discount on their annual membership if they buy a ticket to an event, though I haven't seen that yet.
One change that CiviAccounts will be making to price sets is allowing each option to be associated with a different general ledger account. This would allow, for example, revenue for one type of ticket to go into one account while revenue for a different type of ticket would go into a second account in your bookkeeping system.
The downside of price sets is that they are time consuming to create, and can be confusing for non-techies or new admins. First the price set needs to be created; then each of the fields within it; and within some file types, options can be specified. Lots of steps, clicks, page refreshes, and not intuitive how it will turn out for many CiviCRM admins.
By contrast, it's possible to enter the Fixed Contribution Options directly on the Contribution Amounts tab when configuring a Contribution Page, or select the Membership Types to sell on a page in the Membership Settings tab.
The Regular Fees section on the Fees tab when configuring an Event is just as simple. These simple configuration pages are equivalent to specifying a radio widget option field in a price set, without the complexity or flexibility provided by certain options.
We think it would be good to allow admins to continue to use the simplified interfaces and have the option of the power and flexibility that comes with the complexity of the full price set UI.
Proposed UI Change
In addition, we think it _might_ make sense to allow admins to switch from the simple configuration of a page to editting that information via the more complex price set configuration forms. But not the other way - going from complex to simple.
What's this mean in practical terms? Once any change has been saved to a configuration as a price set, even one that includes only one radio button field, the simple configuration approach for the contribution page or event would not be available for editting it. This would prevent confusion in various ways, e.g. from not seeing in the simplified form a change on the complex forms that was changing the behaviour of the field behaviour. Of course, you could turn off the price set you just created, and go back to the simplified UI and start configuring it from scratch again.
We would expect the price set api to follow our existing structure with an API to get, delete, create each of the Price set entities – Price sets, fields, values and for hooks to be called PRE & POST the main CRUD functions on these entities. The buildForm hook & validate hook are already available for editing price sets. We would probably discontinue the buildAmount.
For API users the change is beneficial with regards to interacting with events. At the moment it is extremely difficult to create events through the api as you also have to create an option group & option values to go with it. More problematically you can’t re-use the same event prices to create a new event via the api so this makes api creation of events much easier (and the eventual implementation of a front end event import option.) It is also currently hard to GET event prices through the API. This is likely to still require the use of API chaining but the chain will be a little more intuitive. Contribution Pages do not yet have an API & the issues are likely to be similar but most sites seem to create many events but only a few contribution page so the relevance is more for events.
Comments or concerns about these change would be appreciated.