How is it different from normal issuing?
External issuing works largely in the same way as the standard issuing process. If an issue is sent to an email address that is tied to a user account on the server, the issue is sent to that user account (and any associated issue notifications are sent to that email address). If, however, the email address does not correspond to an existing user account, an external user account may be created for it. *
This user account is given access exclusively to the issues that are sent to it, and will not be able to access anything else on the system. The user is also unable to see anything other than the issue sheet, as below (note the line ‘These documents are managed in Business Collaborator. You are not a registered user of this server. Your actions are limited.’, indicating that the page is being viewed as an external user):
In the above example, no information about other recipients of the issue or their responses is displayed, It is possible to configure the issues types available in a project such that external users are able to see the distribution of an issue, along with any responses submitted by other users (this is done within the metadata schema in use by that project). In the majority of cases, external user accounts are not able to interact in any way with the issue other than accessing the included documents. *
As an external user is not required to enter a username and password in order to access the issue they have been sent, a different kind of authentication is used. This authentication is via a token embedded in the link to the issue contained within the issue notification email.
This mechanism provides a useful way of determining if you have been sent an issue as an external user – if this is the case, the link will start with the following: https://<ServerName>/token/bc.cgi (rather than https://<ServerName>/bc/bc.cgi).
What to do if the link in the email doesn't work ¶
As a result of the way the token authentication works, only one computer may be authenticated using it. This means that if the link is used from a second computer, irrespective of the user account, the user will fail to authenticate with the server (this means that if the issue notification email is forwarded around a group of users, the user that clicks on the link first will be the one to ‘get’ the token). The following is what a user who does not have the cookie on their computer will see when they try to use the link:
(N.B. If the cookies are cleared on a computer that has authenticated with BC using a cookie, the above message will be encountered.)
If the message above is seen, a new token needs to be generated. This process is started by using the link contained in “Click here to have new login details e-mailed to you” as indicated, Clicking on here will take you to the following page:
You should enter the email address to which the issue
notification was sent in this form – any other email addresses you might use
will not work here. Once the correct email address has been entered, click on Send
new e-mail. The following page will be displayed:
An email containing the following will then be sent to the specified email address:
You should then click on the hyperlinked here to get to the following page:
At this point, your computer is authenticated with the BC server and you should be able to view the issue that was sent to you. Any other computers that you have used to view the issue will not be able to authenticate without going through this same process.
With this in mind, you will now be able to access the issue using the link contained in the original issue notification email.
* This functionality needs to be configured on the metadata schema associated with the project. Note also that only Taskless Reasons for Issue may be used to send external issues. These are Reasons for Issue which don’t assign tasks to the recipient. Typically For Information (for example) is configured to be a Taskless Reason for Issue.