RerouteUserTaskRedirection API¶

Changes the target user of an existing task redirection without modifying the start and end dates. Use this when a user's tasks are already being redirected and you want to point them to a different person.

To create a new redirection from scratch, use SetUserTaskRedirection. To remove a redirection entirely, use RemoveUserTaskRedirection.

Endpoint¶

/srv.asmx/RerouteUserTaskRedirection

Methods¶

• GET /srv.asmx/RerouteUserTaskRedirection?authenticationTicket=...&userName=...&redirectTasksToUser=...
• POST /srv.asmx/RerouteUserTaskRedirection (form data)
• SOAP Action: http://tempuri.org/RerouteUserTaskRedirection

Parameters¶

Response¶

Success Response¶

<response success="true" error="" errorCode="0" />

Error Response¶

<response success="false" error="Access denied." errorCode="4030" />

Required Permissions¶

The calling user must be one of: - The user themselves (self-service -" rerouting their own redirection), or - The user the tasks are currently redirected to (passing them on to somebody else), or - A User Manager, or - A Library Manager.

Anonymous access is not permitted.

Preconditions¶

Rerouting must be allowed: the application setting Allow rerouting of redirected tasks (RerouteRedirections in GetGeneralAppSettings / SetGeneralAppSettings) must be true. It is true by default (a server where it was never saved allows rerouting); once an administrator turns it off, this call is refused with 4030 for every caller, the system administrator included. The setting applies to this call only: SetUserTaskRedirection and RemoveUserTaskRedirection work whatever it says.

The user specified by userName must already have an active task redirection configured. If no redirection exists, the call returns an error. Use SetUserTaskRedirection to create a new redirection.

What Happens on Success¶

The existing task redirection for userName is updated so that tasks are forwarded to redirectTasksToUser instead of the previous target. The start date and end date from the existing redirection are preserved (the start date may be adjusted to the current time if the original start date is already in the past).

Example¶

GET Request¶

GET /srv.asmx/RerouteUserTaskRedirection
    ?authenticationTicket=3f7a1b2c-4d5e-6f7a-8b9c-0d1e2f3a4b5c
    &userName=john.smith
    &redirectTasksToUser=alice.jones
HTTP/1.1
Host: yourserver

POST Request¶

POST /srv.asmx/RerouteUserTaskRedirection HTTP/1.1
Host: yourserver
Content-Type: application/x-www-form-urlencoded

authenticationTicket=3f7a1b2c-4d5e-6f7a-8b9c-0d1e2f3a4b5c&userName=john.smith&redirectTasksToUser=alice.jones

JavaScript¶

Every call answers XML with HTTP 200, success or not, so success is the thing to branch on and errorCode is the number to report.

async function call(action, params) {
  const response = await fetch(`/srv.asmx/${action}?${new URLSearchParams(params)}`);
  const root = new DOMParser()
    .parseFromString(await response.text(), 'text/xml')
    .documentElement;

  if (root.getAttribute('success') !== 'true') {
    throw new Error(`${root.getAttribute('errorCode')}: ${root.getAttribute('error')}`);
  }
  return root;
}

Points an existing redirection at a different user, keeping its dates.

await call('RerouteUserTaskRedirection', {
  authenticationTicket: ticket,
  userName: 'jsmith',
  redirectTasksToUser: 'bpatel'
});

Calling it for a user who has nothing redirected answers 4041 and says so. Until 9.0 it answered 4000 with an empty error - the code returned its own successful authorization check as a failure - so the caller was told it had failed and not why.

Notes¶

• Until 9.0 the RerouteRedirections setting was not checked by this call; it only decided whether the user interface showed the Reroute link. A server whose stored value is false now refuses rerouting until the setting is turned on.
• Until 9.0 the user the tasks are redirected to was refused (4030) unless they were also allowed to set the redirection, so only the user themselves and managers could reroute.
• This API only changes the redirection target. The date window is inherited from the existing record.
• If you need to change both the target and the date window, remove the existing redirection with RemoveUserTaskRedirection and create a new one with SetUserTaskRedirection.
• To verify the updated redirection, use GetUserTaskRedirectionTo.

Related APIs¶

• GetUserTaskRedirectionTo -" Get the current redirection target for a user.
• GetUserTaskRedirectionsFrom -" Get all users who are redirecting their tasks to a specified user.
• SetUserTaskRedirection -" Set or update a task redirection with a specific date window.
• RemoveUserTaskRedirection -" Remove a user's task redirection.

Error Codes¶

The errorCode values this operation returns, checked against a running server: