Support
Important Information For jxAPI Users Regarding Timesheet 7.7
If you are currently using a Timesheet integration employing the Journyx API (jxAPI), you should read this notice before upgrading to Timesheet 7.7.
Timesheet was originally created with user login names as the unique ID field for the users table, partially as a means of guaranteeing uniqueness in user logins. The end result of this decision was that administrators were unable to change user logins without losing existing data for those users.
Due to continued customer demand, we have introduced the ability to change user login names in Journyx Timesheet Version 7.7. While this change will be performed seamlessly on existing databases that are migrated to version 7.7, you will be required to make some minor changes to existing API code in order to preserve functionality for the new release.
A Brief Explanation of User Data
Timesheet data for users, user custom field values, time entries, etc. is stored by the user's unique ID. Whenever the product displays this information, it uses the ID to look up the user in the users table and then displays the user full name or user login, as appropriate. Other tables in Timesheet function similarly, displaying a "pretty name" in the product, while storing and accessing records based on a unique ID field.
User Data and the API Prior to Timesheet 7.7
Formerly, the user login name was used as the user's unique ID. If you had a list of all of your user login names, you could circumvent the step of looking up a user record and simply call API methods (e.g. createUserAccrual) directly by passing in the login name as the ID parameter. This particular shortcut will still function for users who were already present prior to the 7.7 upgrade, but you should update your API code now, as future users will not be accessible in this fashion.
User Data and the API in Timesheet 7.7
To create time, expense, or mileage records, look up user custom field values, set accruals, or other user-related functions via the API, you will now need to look up the user ID first before making additional API calls. This process still uses the getUser method. If you have been using this method to look up users by full name, then your code does not need to change. If you have been using user login names, however, then you will need to alter the search pattern to read "user_login": <user login name>, rather than using the "user_id": <user login name> search pattern that you were using prior to version 7.7.
Once you have updated your API code to look up your users properly, no further changes should be required to continue using the API.
Return to the Timesheet 7.7 Migration Information Page.
