com.atlassian.jira.bc.user.UserService |
Known Indirect Subclasses |
Clients of @PublicApi
can expect
that programs compiled against a given version will remain binary compatible with later versions of the
@PublicApi
as per each product's API policy as long as the client does not implement/extend
@PublicApi
interfaces or classes (refer to each product's API policy for the exact
guarantee---usually binary compatibility is guaranteed at least across minor versions).
@PublicApi
interfaces and classes are not designed to be implemented or extended by clients,
we may perform certain types of binary-incompatible changes to these classes and interfaces, but these will not
affect well-behaved clients that do not extend/implement these types (in general, only classes and interfaces
annotated with @PublicSpi
are safe to extend/implement).
UserService provides User manipulation methods exposed for remote API and actions.
Nested Classes | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
UserService.AddUserToApplicationValidationResult | |||||||||||
UserService.CreateUserRequest | This request contains all the instructions and user details that should be used during user validation and user creation. | ||||||||||
UserService.CreateUserValidationResult | |||||||||||
UserService.CreateUsernameValidationResult | |||||||||||
UserService.DeleteUserValidationResult | |||||||||||
UserService.FieldName | |||||||||||
UserService.RemoveUserFromApplicationValidationResult | |||||||||||
UserService.UpdateUserValidationResult |
result | the validation result |
---|
AddException | the underlying directory implementation failed to add user to group |
---|---|
PermissionException | the underlying directory has been configured to not allow user to be added to group, or the directory/group is read-only |
Create a new application user if the provided isValid()
. This is typically
called after performing validateCreateUser(CreateUserRequest)
and verifying that the isValid()
. If the request is not valid or validateCreateUser(CreateUserRequest)
was not called prior to this method an IllegalStateException
would get thrown.
createUserValidationResult | create user validation result returned from validateCreateUser(CreateUserRequest) , this contains the user details and instructions used to create new
user. |
---|
PermissionException | when the logged in user does not have permissions to perform user creation or when the user directory is read-only. |
---|---|
CreateException | if the user could not be created for any reason, eg username already exists |
This method is deprecated.
Use createUser(CreateUserValidationResult)
instead. Since v7.0.
Given a valid validation result, this will create the user using the details provided in the validation result. Email notification will be send to created user - via UserEventType.USER_SIGNUP event.
result | The validation result |
---|
CreateException | if the user could not be created, eg username already exists |
---|---|
PermissionException | If you cannot create users in this directory (it is read-only). |
This method is deprecated.
Use createUser(CreateUserValidationResult)
instead. Since v7.0.
Given a valid validation result, this will create the user using the details provided in the validation result. No email notification will be send to created user.
result | The validation result |
---|
CreateException | if the user could not be created, eg username already exists |
---|---|
PermissionException | If you cannot create users in this directory (it is read-only). |
This method is deprecated.
Use createUser(CreateUserValidationResult)
instead. Since v7.0.
Given a valid validation result, this will create the user using the details provided in the validation result. Email notification will be send to created user - via UserEventType.USER_CREATED event.
result | The validation result |
---|
CreateException | if the user could not be created, eg username already exists |
---|---|
PermissionException | If you cannot create users in this directory (it is read-only). |
@Internal
or @PublicApi
.
Allows you to construct ApplicationUser
for validateUpdateUser(ApplicationUser)
This method is deprecated.
Use removeUser(ApplicationUser, DeleteUserValidationResult)
instead. Since v6.0.
Given a valid validation result, this will remove the user and removes the user from all the groups. All components lead by user will have lead cleared.
loggedInUser | the user performing operation |
---|---|
result | The validation result |
Given a valid validation result, this will disassociate a user from an application by removing that user from all the groups assigned to that application. This also validates if the directory where the user lives is not fully read-only.
If the group set assigned to this application is a superset of the group set assigned to other application(s), the user will also be disassociated with those applications as well.
This method is not the exact opposite to addUserToApplication(UserService.AddUserToApplicationValidationResult)
.
While this method removes user from all the group assigned to an application, addUserToApplication method
only adds user to the default groups assigned to an application
result | The validation result |
---|
RemoveException | the underlying directory implementation failed to remove user from group |
---|---|
PermissionException | the underlying directory has been configured to not allow user to be removed from group, or the directory/group is read-only |
Execute the update using the validation result from validateUpdateUser(ApplicationUser)
.
updateUserValidationResult | Result from the validation, which also contains all the user's details. |
---|
IllegalStateException | if the validation result contains any errors. |
---|
Validates associating a user with an application. This method checks if the logged in user has the permission to add user to application. It then checks if there is an application specified by the application key. It also checks if there are any default groups assigned to that application. It validates if there are any spaces in the application license as well. This also validates if the directory where the user lives is not fully read-only.
loggedInUser | The logged in user |
---|---|
user | the user to be associated with the application |
applicationKey | the key of the application |
This method is deprecated.
Use validateAddUserToApplication(ApplicationUser, ApplicationUser, ApplicationKey)
instead. Since v7.0
Validates associating a user with an application. This method checks there is an application specified by the application key. It also checks if there are any default groups assigned to that application. It validates if there are any spaces in the application license as well. This also validates if the directory where the user lives is not fully read-only.
user | the user to be associated with the application |
---|---|
applicationKey | the key of the application |
Validate that a new user can be created.
The validation instructions are specified in the UserService.CreateUserRequest
.
Typical validations are:
createUser(CreateUserValidationResult)
should only be called when the validationResult.isValid().
Usage example:
final CreateUserRequest createUserRequest = CreateUserRequest.withUserDetails(currentApplicationUser,
username, password, email, displayName)
result = userService.validateCreateUser(createUserRequest);
if(result.isValid())
{
userService.createUser(createUserRequest);
}
This request indicates that the user should be created in the default user directory with access to the default
applications.
createUserRequest | user creation request containing new user details and validation instructions. |
---|
This method is deprecated.
Use validateCreateUser(CreateUserRequest)
instead. Since v7.0.
Validates creating a user for the admin section. This method checks that external user management is disabled and that the user performing the operation has global admin rights. It also validates that all parameters (username, email, fullname) except for the password have been provided. Email is also checked to ensure that it is a valid email address. The username is required to be lowercase characters only and unique. The confirmPassword has to match the password provided.
This method allows the caller to name a directory to create the user in and the directoryId must be valid and represent a Directory with "create user" permission.
This validation differs from the 'ForSetup' and 'ForAdminPasswordRequired' validations as follows:
loggedInUser | The remote user trying to add a new user |
---|---|
username | The username of the new user. Needs to be lowercase and unique. |
password | The password for the new user. |
confirmPassword | The password confirmation. Needs to match password. |
The email for the new user. Needs to be a valid email address. | |
fullname | The full name for the new user |
directoryId | The User Directory |
This method is deprecated.
Use validateCreateUser(CreateUserRequest)
instead. Since v7.0.
Validates creating a user for the admin section. This method checks that external user management is disabled and that the user performing the operation has global admin rights. It also validates that all parameters (username, email, fullname) except for the password have been provided. Email is also checked to ensure that it is a valid email address. The username is required to be lowercase characters only and unique. The confirmPassword has to match the password provided.
This validation differs from the 'ForSetup' and 'ForAdminPasswordRequired' validations as follows:
loggedInUser | The remote user trying to add a new user |
---|---|
username | The username of the new user. Needs to be lowercase and unique. |
password | The password for the new user. |
confirmPassword | The password confirmation. Needs to match password. |
The email for the new user. Needs to be a valid email address. | |
fullname | The full name for the new user |
This method is deprecated.
Use validateCreateUser(CreateUserRequest)
instead. Since v7.0.
Validates creating a user during setup of JIRA. This method does not check for a writable User Directory because the embedded crowd subsystem will not be initialised, and we know we will just have an Internal Directory during Setup. It also validates that all parameters (username, email, fullname, password) have been provided. Email is also checked to ensure that it is a valid email address. The username is required to be lowercase characters only and unique. The confirmPassword has to match the password provided.
This validation differs from the 'ForAdminPasswordRequired' and 'ForAdmin' validations as follows:
loggedInUser | The remote user trying to add a new user |
---|---|
username | The username of the new user. Needs to be lowercase and unique. |
password | The password for the new user. |
confirmPassword | The password confirmation. Needs to match password. |
The email for the new user. Needs to be a valid email address. | |
fullname | The full name for the new user |
This method is deprecated.
Use validateCreateUser(CreateUserRequest)
instead. Since v7.0.
Validates creating a user during public signup. This method checks that there is a writable User Directory available. It also validates that all parameters (username, email, fullname, password) have been provided. Email is also checked to ensure that it is a valid email address. The username is required to be lowercase characters only and unique. The confirmPassword has to match the password provided.
This validation differs from the 'ForAdminPasswordRequired' and 'ForAdmin' validations as follows:
loggedInUser | The remote user trying to add a new user |
---|---|
username | The username of the new user. Needs to be lowercase and unique. |
password | The password for the new user. |
confirmPassword | The password confirmation. Needs to match password. |
The email for the new user. Needs to be a valid email address. | |
fullname | The full name for the new user |
This method is deprecated.
Use validateCreateUser(CreateUserRequest)
instead. Since v7.0.
Validates creating a user during setup of JIRA or during public signup. This method checks that there is a writable User Directory available. It also validates that all parameters (username, email, fullname, password) have been provided. Email is also checked to ensure that it is a valid email address. The username is required to be lowercase characters only and unique. The confirmPassword has to match the password provided.
This validation differs from the 'ForAdminPasswordRequired' and 'ForAdmin' validations as follows:
user | The remote user trying to add a new user |
---|---|
username | The username of the new user. Needs to be lowercase and unique. |
password | The password for the new user. |
confirmPassword | The password confirmation. Needs to match password. |
The email for the new user. Needs to be a valid email address. | |
fullname | The full name for the new user |
Validates the username for a new user. The username is required to be lowercase characters only and unique in the given directory.
loggedInUser | The remote user trying to add a new user |
---|---|
username | The username of the new user. Needs to be lowercase and unique. |
directoryId | The directory which the new user is intended to be created in. |
Validates the username for a new user. The username is required to be lowercase characters only and unique across all directories.
loggedInUser | The remote user trying to add a new user |
---|---|
username | The username of the new user. Needs to be lowercase and unique. |
Validates removing a user for the admin section. This method checks that external user management is disabled and that the user performing the operation has global admin rights. It also validates that username have been provided.
See validateDeleteUser(ApplicationUser, ApplicationUser)
for restrictions.
loggedInUser | The remote user trying to remove a user |
---|---|
username | The username of the user to remove. Needs to be valid |
Validates removing a user for the admin section. This method checks that external user management is disabled and that the user performing the operation has global admin rights. It also validates that username have been provided.
Removing the user is not allowed if:
PreDeleteUserErrors
rejects the requestloggedInUser | The remote user trying to remove a user |
---|---|
userForDelete | The user to remove. Needs to be valid |
@Internal
classes and interfaces can not expect to be compatible with any version
other than the version they were compiled against (even minor version and milestone releases may break binary
compatibility with respect to @Internal
elements).
This method is deprecated.
Use validateRemoveUserFromApplication(com.atlassian.jira.user.ApplicationUser, com.atlassian.jira.user.ApplicationUser, com.atlassian.application.api.ApplicationKey)
instead. Since v 7.0.0.
Validates disassociating a user from an application. This method checks there is an application specified by the application key.
Method expects for loggedInUser to be available via getLoggedInUser()
.
user | the user to be disassociated with the application |
---|---|
applicationKey | the key of the application |
Validates disassociating a user from an application. This method checks there is an application specified by the application key.
loggedInUser | application user performing the application access removal |
---|---|
user | the user to be disassociated with the application |
applicationKey | the key of the application |
Validates updating a user's details.
user | The user details to update |
---|