Sandbox Release Date |
March 14th, 2018 |
Production Release Date |
April 18th, 2018 |
Important
For those organizations who are on a Skedulo long term support arrangement—please check your sandboxes to see if this new package has been deployed successfully (the deployment will be performed on ***). If this package is not installed, you will need to make arrangements to deploy it manually to your sandboxes (to test) before *** (see Manual Installation Links).
Description |
---|
Ignore assets' job allocation status when determining job status. Assets are never assigned a user license and as such can never progress a job status–so their allocation status should be ignored. |
Changes to update estimated and actual start and end times on jobs. Fixed an issue where the estimated start and end times are not populated on job creation. This has been fixed. |
Prevent deletion of resource if it has related job allocation or activity. Currently, if a resource has a related job allocation or activity, deleting it will delete the job allocation and leave the activity orphaned. The correct behavior should be to prevent deletion of resource if it has related job allocation or activity. |
Added read permission to the scheduler and resource permission sets for push topics. This resolves an issue we're seeing in Skedulo Classic where job states were not updating via the HTML5 app. This is due to some customers using a modified profile, where push topics access hasn't been granted. |
Added support for assigning shifts to resources. Add a new shift object that defines the assigned working hours for a resource for a particular period of time. |
Removed validation rule that prevented jobs > 24 hours. Skedulo currently has a limitation that requires jobs to be <= 24 hours. This limitation is no longer required and so this validation rule has been disabled. |
Added the "Resource Requirement" and "Resource Requirement Tag" objects. Also added the following fields: "Quantity" (on the "Job" object) and "Resource Requirement" (on the "Job Allocation" object). Initially, these objects and fields will not be used by the application but will be reserved for future use. Customers do not have to grant users permissions to these objects and fields at this time. |
Comments
0 comments
Article is closed for comments.