Hey all, two things to discuss today:
This release included some really finicky, technically logic so it took a while to get it right. But no matter! Today Form Tools 3.0.13 was rolled out, which includes these nice new features:
Conflict resolution for submission editing
When editing data there’s always the risk of two people updating the same form fields at the same time. For low volume installations this is pretty unlikely, but the more users you have and the more active they are, the probability of this occurring starts to creep up and up.
To mitigate this, historically we’ve had the Submission History module: that lets you track changes to form data over time so you can revert back to any version if you need. But honestly, a better solution would be to just catch these conflicts right when they occur.
That’s what 3.0.13 adds. Now in case of a conflict, the system updates as much of the data as it can and prompts the user to reconcile the rest. Do you want to keep the data you just added for Field X, or choose the one that was in the database? Give this page a read over to get a better idea of how it works:
This is something of a “hidden” feature – you won’t ever see it until it actually becomes an issue.
Better integration for Client Map filters
Client Map filters always had the promise of being super-useful… they let you map a specific View to a particular value in a client account, so when two different clients log in and browse submissions within a particular form View, they’d see different things. Cool! But the problem was that it was really a feature designed for External Forms where you could easily load up the initial form POST with a specific setting (like “client_id” => X) so all submissions would be mapped properly by default. But Form Builder Forms? Internal forms? Not so easy. For those, you had to do some elaborate workarounds using the Submission Pre-Parser module to pull out client info from sessions and populate the form submissions are they were created. This was very fussy and complicated.
3.0.13 greatly simplifies this. Now you can now use placeholders in the Default Values for New Submissions field on the Edit View -> main tab, so those values get automatically inserted for all new submissions in that View.
Here are a couple of links to help understand the feature:
- Tutorial: configuring client accounts to only edit their own form
- Edit View -> main tab documentation
Oh and also, I just released a new version of the Extended Client Fields module (2.1.0) so you can also use placeholders for all fields in that module in the Edit View fields as well. It works exactly the same way. You extend the client accounts to store any arbitrary data you want about a client (e.g. a “department” or “area of interest” field) then after its been populated for each user, use a placeholder for that field in your View & any submissions created by client accounts will imprint their submissions with the appropriate data from their account, thus showing up in their View. Give the tutorial a read over for more info.
So that’s 3.0.13! But there’s one other thing I wanted to talk about today…
Where indeed!? Back after I release 3.0, I vowed I’d never do another “big bang” release – a long, drawn out new version which took ages to complete and risked introducing a huge thwack of regression. With that in the back of my mind I launched right into 3.1 and… yeah, you guessed it, a few months passed and before I knew it I was in exactly the same boat as before.
For people who’ve been following it on Github, I’ve actually gotten a fair bit of work done on 3.1 already, but it’s still destined to become another Big Bang release. I fixed various things in that version which I’m finding I’m having to duplicate in the 3.0.x releases because it was just taking too long.
So, enough of this nonsense! Here’s what I’m going to do.
masterbranch on github is back to the 3.0.x branch. That is the main release branch where I work on new features.
- I’m going to start cherry-picking fixes/improvements I’ve made in the 3.1 branch and start introducing them into 3.0.x and incrementally add them in. So you can anticipate smaller 3.0.14, 3.0.15 etc. releases – as many as it takes.There will still be a big “3.1” release when I’m ready to flip the switch, but it won’t be a nail-biter sort of oh-god-will-this-break-everything kind of a release. The majority of the features will have been introduced in the 3.0 branch so upgrading should be less of a worry.
Alright! That’s the plan! See you on the interwebs.