It has been a busy few months of training which has contributed to a delay of 3 months since the last monthly update. However here at last is a new release for May.
A new Change password page
Previously a user clicked on the user profile menu item and then, in the dialog that popped up, they would select “Reset Password”. Now when you click on the user profile menu item you will see three sub menus.
- “User Profile” takes you to the user profile dialog where you can change your current organisation, timezone, name etc.
- “Change Password” takes you to the new Change Password page
- Logout, logs you out of the application. This was previously also in the user profile dialog.
The change password page includes a button that will generate a random password for you. After you change your password and move to another page you will be asked to logon again. After you have done that your browser can remember, if you agree, the new password that you have used.
Improved role security
Previously if a survey had a role then an administrator, who also had that role, could add a new survey to the same bundle. This could be a problem if the role on the survey had column or row restrictions as the administrator could then by pass these restrictions. Now only an administrator who also has security manager privilege, can bundle new surveys to a survey that has roles. The security manager can then set any required row or column filtering on the new bundled survey.
Add the ability to force password expiry
The date a password is set is now recorded and the server owner can specify that all passwords older than that must be updated.
When automatically escalating a case to a new user after a console alert or record update you can now also send an email to someone notifying them of the escalation.
Another new feature is that a checkbox can be selected to send an email to the person who has been assigned, notifying them of their new case. This only works if the assigned user has an email specified in their profile.
Allow a form to explicitly set the key value
A user can specify that a survey form has a unique key and a key policy. Then records submitted with that key will be treated according to the key policy, merge, replace, discard or none (append).
However some times it is not possible to identify the components of the key when completing a survey. For example the key could be defined as:
So in the above case submissions with the same surname will not be considered as duplicates instead a unique number will be append. For example:
Smith-1 Jones-1 Smith-2
So to update these records you can use tasks and case management. But what if you wanted to do an ad-hoc update. This might occur if you go to a location and realise that there is new information to add to the record.
You can use the search() function in your survey form to download the key, such as “Jones-2”. This search function can use multiple questions such as name, age, address, gender to uniquely identify the record to be updated. If you now store the results of the search function in a question with name “_hrk” then that value will be used as the unique key on submission.
Other changes and bug fixes
- Remove the warning that used to be shown when a survey form was created that had a group filled only with calculations.
- In the console you can filter directly on the user name who submitted a record and the name of the user that the record is assigned to.
- Clear the saved advanced query in the console if it causes an error.
- Improve the efficiency of the uploading of submissions so that is uses less CPU and is faster.
- Fix an issue with the API call to get a submissions list which would fail if GPS coordinates were malformed
- Fix an issue with the preservation of a record’s unique key between record updates if that key inlcuded a seq() or serial() function.
- Added additional event logging
- Prevent a new organisation name from being specified that differs only in case. So we won’t now have organisations like Acme and acme and aCme registered on the SG server.
- Fixed an issue that prevented initiating tasks from the console.
- Allow administrators to move projects to one of their private organisations.
- Remove the ability to move a user to new organisation Users should instead be granted access to organisations in their user settings by an administrator. They can then move themselves using the user profile dialog.
- Fix issues when uploading empty data into a survey form from a file. This empty data was being set to text without characters, or in the case of a geopoint question, to a location of 0.0 0.0. The values will now be set to undefined as they would be if submitted from fieldTask.
- Fix an issue where an non valid period to wait for a console alert could be set. This non valid period would stop processing of console alerts.
- Fixed an error that prevented polygons from being used as default areas when accessed by the pulldata() function from a WebForm.
- Fixed an issue with generating the default link to a survey form in a campaign email when the location of the link was not specified in the email content.
- On the analysis page allow charts to group data by “note” type questions. This change recognizes that people are commonly setting values to note questions using dynamic defaults.
- Add improved validation of XLSForms that have non valid headings on the choices worksheet.
- Group outputs in the administration usage report by the survey identifier rather than the survey id. This means that replaced surveys will be considered the same survey in the report.
- Add an option to the administration usage report to not include “All time” usage.
- Upgraded multiple software libraries that had become out of date and had security issues flagged against them.
- Fix an issue where the cache of a WebForm was not being updated when the survey definition had changed. This was occurring if the WebForm opened an existing record.
- Increase the maximum number of records shown in a map, on the analysis page, to 10,000 from 1,000.