Syncplicity DataHub 4 Save PDF Selected topic Selected topic and subtopics All content Directory of Syncplicity documentation Job reset options Reset options control how DataHub will re-evaluate tracking state or permission propagation on the next job execution Usage Executing a reset call simply sets the corresponding flags in the database The job must be executed in order for the change to take effect REST API Options soft This will preserve tracking state but prevent the use of native change detection on the next execution More information: Job Reset | Soft Soft Reset PATCH {{url}}v1/jobs/{{job}}?reset=soft permissions This will force the re-application of permissions. Note, DataHub will not remove previously added permissions. During a permissions reset the entire hierarchy is traversed to evaluate permissions. Change detection is not used during this execution and consequently events such as deletes are not processed. However, those events will be evaluated on the following execution. More information: Job Reset | Permissions Permissions Reset PATCH {{url}}v1/jobs/{{job}}?reset=permissions stats This will force the transfer statistics roll-up tables to be rebuilt at the very start of the next execution More information: Job Reset | Statistics Statistics Reset PATCH {{url}}v1/jobs/{{job}}?reset=stats Using reset options hard or full, will reset your reporting values on the Overview Transfer Details report in the DataHub User-Interface (UI) This is expected since these options have reset all tracking states This will not delete the job tracking data from the database hard This will reset all tracking state and prevent the use of native change detection on the next execution More information: Job Reset | Hard Hard Reset PATCH {{url}}v1/jobs/{{job}}?reset=hard full (?reset=1) This will be a full/complete reset. It is equivalent to hard + permissions reset More information: Job Reset | Complete / Full Full Reset PATCH {{url}}v1/jobs/{{job}}?reset=1 soft & start This will reset and start a job with one call. Soft reset and run the job PATCH {{url}}v1/jobs/{{job}}?reset=soft&start Summary The job resets related to validation inspect options allow a job execution to traverse all folders, including those that are ignored / skipped due to policy, to record information about that folder for tracking and reporting for both the source and the destination This feature operates the Job Validation Report | item_inspection_policy ReST API - Validation Reset Options Options include: inspect_filtered This job reset will re-evaluate all filtered content on both the source and destination in the next job run after the reset is executed; including content ignored due to policy configured for job filters, hidden and content shared to the transfer owner inspect_filtered 1 PATCH {{url}}v1/jobs/{{job}}?reset=inspect_filtered inspect_shared This job reset will re-evaluate all shared content on both the source and destination in the next job run after the reset is executed; including content ignored due to policy configured to excluded data not owned by the transfer author / owner inspect_shared 1 PATCH {{url}}v1/jobs/{{job}}?reset=inspect_shared inspect_all This job reset will re-evaluate all content on the source and destination in the next job run after the reset is executed; including content ignored due to policy configured for filters and shared inspect_all 1 PATCH {{url}}v1/jobs/{{job}}?reset=inspect_all What reset configurations align with the application user-interface? Validation | Track Everything 1 "item_inspection_policy": "all" will produce the same results as a inspect_all 1 PATCH {{url}}v1/jobs/{{job}}?reset=inspect_all Validation tab in the UI when both of these options are checked Inspect filtered items Inspect shared items makes the same call as inspect_all 1 PATCH {{url}}v1/jobs/{{job}}?reset=inspect_all Validation tab in the UI when this item is checked Inspect filtered items makes the same call as inspect_filtered 1 PATCH {{url}}v1/jobs/{{job}}?reset=inspect_filtered Validation tab in the UI when this item is checked Inspect shared items makes the same call as inspect_shared 1 PATCH {{url}}v1/jobs/{{job}}?reset=inspect_shared User-Interface - Export Items Report In the DataHub application, exporting the items report will have a status column where skipped content will be recorded. For each skipped entry, observe the value for the source_exists and destination_exists columns source_exists = true This means DataHub has identified the skipped item destination_exists = false This means DataHub has identified but did not transfer the item Related Links
Directory of Syncplicity documentation Job reset options Reset options control how DataHub will re-evaluate tracking state or permission propagation on the next job execution Usage Executing a reset call simply sets the corresponding flags in the database The job must be executed in order for the change to take effect REST API Options soft This will preserve tracking state but prevent the use of native change detection on the next execution More information: Job Reset | Soft Soft Reset PATCH {{url}}v1/jobs/{{job}}?reset=soft permissions This will force the re-application of permissions. Note, DataHub will not remove previously added permissions. During a permissions reset the entire hierarchy is traversed to evaluate permissions. Change detection is not used during this execution and consequently events such as deletes are not processed. However, those events will be evaluated on the following execution. More information: Job Reset | Permissions Permissions Reset PATCH {{url}}v1/jobs/{{job}}?reset=permissions stats This will force the transfer statistics roll-up tables to be rebuilt at the very start of the next execution More information: Job Reset | Statistics Statistics Reset PATCH {{url}}v1/jobs/{{job}}?reset=stats Using reset options hard or full, will reset your reporting values on the Overview Transfer Details report in the DataHub User-Interface (UI) This is expected since these options have reset all tracking states This will not delete the job tracking data from the database hard This will reset all tracking state and prevent the use of native change detection on the next execution More information: Job Reset | Hard Hard Reset PATCH {{url}}v1/jobs/{{job}}?reset=hard full (?reset=1) This will be a full/complete reset. It is equivalent to hard + permissions reset More information: Job Reset | Complete / Full Full Reset PATCH {{url}}v1/jobs/{{job}}?reset=1 soft & start This will reset and start a job with one call. Soft reset and run the job PATCH {{url}}v1/jobs/{{job}}?reset=soft&start Summary The job resets related to validation inspect options allow a job execution to traverse all folders, including those that are ignored / skipped due to policy, to record information about that folder for tracking and reporting for both the source and the destination This feature operates the Job Validation Report | item_inspection_policy ReST API - Validation Reset Options Options include: inspect_filtered This job reset will re-evaluate all filtered content on both the source and destination in the next job run after the reset is executed; including content ignored due to policy configured for job filters, hidden and content shared to the transfer owner inspect_filtered 1 PATCH {{url}}v1/jobs/{{job}}?reset=inspect_filtered inspect_shared This job reset will re-evaluate all shared content on both the source and destination in the next job run after the reset is executed; including content ignored due to policy configured to excluded data not owned by the transfer author / owner inspect_shared 1 PATCH {{url}}v1/jobs/{{job}}?reset=inspect_shared inspect_all This job reset will re-evaluate all content on the source and destination in the next job run after the reset is executed; including content ignored due to policy configured for filters and shared inspect_all 1 PATCH {{url}}v1/jobs/{{job}}?reset=inspect_all What reset configurations align with the application user-interface? Validation | Track Everything 1 "item_inspection_policy": "all" will produce the same results as a inspect_all 1 PATCH {{url}}v1/jobs/{{job}}?reset=inspect_all Validation tab in the UI when both of these options are checked Inspect filtered items Inspect shared items makes the same call as inspect_all 1 PATCH {{url}}v1/jobs/{{job}}?reset=inspect_all Validation tab in the UI when this item is checked Inspect filtered items makes the same call as inspect_filtered 1 PATCH {{url}}v1/jobs/{{job}}?reset=inspect_filtered Validation tab in the UI when this item is checked Inspect shared items makes the same call as inspect_shared 1 PATCH {{url}}v1/jobs/{{job}}?reset=inspect_shared User-Interface - Export Items Report In the DataHub application, exporting the items report will have a status column where skipped content will be recorded. For each skipped entry, observe the value for the source_exists and destination_exists columns source_exists = true This means DataHub has identified the skipped item destination_exists = false This means DataHub has identified but did not transfer the item