This article describes changes to some public Traction SDK APIs. This is one of those rare times when existing APIs have been removed or changed in such a way that existing code based upon them may break. If you have custom code in Traction TeamPage plug-ins that relies upon any of these APIs, please make sure your plug-ins still compile, or consult the information below to learn how to change your code.
The type parameters for the Login interface and the LoginKey abstract class have been changed. The old signatures were:
public interface Login<L extends Login<L,K>, K extends LoginKey<L>>
public abstract class LoginKey<T extends Login> implements Serializable
The new signatures are:
public interface Login<L extends Login<L>>
public abstract class LoginKey<L extends Login<L>> implements Serializable
This is a more compact representation of the same type relationship. This change should not break any code which came before TeamPage 6.0, since LoginKey is new to 6.0 and Login never had type parameters before 6.0.
This is a new class which represents an internationalizable message, with optional parameters, which is identified by the combination of a message type mnemonic and a numeric code. This is used in some of the code changes described below.
The following methods have been removed:
public void forceLogin(Context context, String message) throws ViewCompleteException;
public void forceLogin(TractionRequest req, TractionResponse res, String message) throws ViewCompleteException;
To force the user to log in, client code must invoke one of TractionSecurityManager's check*X methods to trigger an appropriate AuthenticationException or other TractionSecurityException, and then invoke its bail method (or use the static method com.traction.sdk.TractionSecurityException.sendLoginPrompt, passing the TractionSecurityException as an argument).
This method has been added to simpy throw an AuthenticationException if the TractionSecurityManager User is not a named user (i.e., is not the built-in Visitor, Owner or (super) account).
public void checkNamedAccountX() throws AuthenticationException;
The following methods have also been removed:
public boolean checkAccessQ(Project proj);
public void checkAccessX(Project proj) throws AuthenticationException;
public boolean checkSeeProjectQ(Project proj);
These methods are not applicable because it is not possible from Traction's public SDK API to access a Project object on behalf of a User who does not have Access permission (i.e., cannot "see" or ever be given any information to confirm the existence of the space).
The following methods have been added:
public boolean checkCreateNewAttachmentQ(Project proj);
public void checkCreateNewAttachmentX(Project proj) throws AuthenticationException, LicenseException, MessageException;
These methods test whether the User has Add Attachments permission in a particular space in which they also have at least some Author or Edit permission.
public boolean checkEmailOutQ();
public void checkEmailOutX() throws AuthenticationException, LicenseException, ConfigurationException;
These methods test whether the User will be allowed to use the Email Articles ("Email Out") feature. This is based partly upon whether the feature is available to the user (the Visitor account by default is not eligible to use the feature, but this can be changed), partly upon whether the user has the Email Out server permission, and partly upon whether server administrators have configured and enabled outgoing email.
TractionSecurityManager's developer documentation has also been extensively updated and refined.
This enum defines the types of violations to built-in security policies, each mapped to a unique code. These cover only those types of attempted requests or operations that another user might be allowed to complete, but which the requesting user is not allowed to complete. (There is no guarantee that any particular user would have the necessary permissions to complete the attempted request or operation, but at least these errors do not relate to configuration, license, or other issues that definitely prevent any user from having the attempted request or operation complete successfully.)
The UserDirectoryException constructors which take Strings for error messages have been removed and replaced with versions that accept MessageWithParameters instead. Here are the constructors which have been removed:
public UserDirectoryException(String message, Login<?> login, UserDirectoryComponent component)
public UserDirectoryException(String message, Login<?> login, UserDirectoryComponent component, Throwable cause)
Here are the new constructors:
public UserDirectoryException(Login<?> login, UserDirectoryComponent component, FormattedMessage message)
public UserDirectoryException(Login<?> login, UserDirectoryComponent component, FormattedMessage message, Throwable cause)The promptLogin method has changed so that it no longer accepts a String for an arbitrary error message. This is the old signature:
public void promptLogin(TractionRequest req, TractionResponse res, Login<?> login, String loginMessage, String afterLoginURL)
throws UserDirectoryException, IOException;
This is the new signature:
public void promptLogin(TractionRequest req, TractionResponse res, Login<?> login, FormattedMessage message, String afterLoginURL)
throws UserDirectoryException, IOException;
This class has been removed. The enum SecurityViolationType takes the place of this class. Although it does not provide direct access to the same error messages that LoginMessage provided, those error messages should only be generated by TractionSecurityManager methods, or the methods of other SDK implementation classes.