theonedev/onedev · error · NotAcceptableException

Cannot set email address for service or ai user

Error message

Cannot set email address for service or ai user

What it means

Email addresses may only be attached to ORDINARY type users in OneDev. Service accounts and AI users are non-human identities that do not use email addresses, so the endpoint rejects them with NotAcceptableException. This applies even to administrators.

Source

Thrown at server-core/src/main/java/io/onedev/server/rest/resource/EmailAddressResource.java:79

	@Path("/{emailAddressId}/verified")
	@GET
	public boolean isEmailAddressVerified(@PathParam("emailAddressId") Long emailAddressId) {
		EmailAddress emailAddress = emailAddressService.load(emailAddressId);
    	if (!SecurityUtils.isAdministrator() && !emailAddress.getOwner().equals(getAuthUser())) 
			throw new UnauthorizedException();
    	return emailAddress.isVerified();
	}
	
	@Api(order=200, description="Create new email address")
	@POST
	public Long createEmailAddress(@NotNull @Valid EmailAddress emailAddress) {
		var owner = emailAddress.getOwner();
		if (!SecurityUtils.isAdministrator() && !owner.equals(getAuthUser()))
			throw new UnauthorizedException();
		else if (owner.isDisabled())
			throw new NotAcceptableException("Cannot set email address for disabled user");
		else if (owner.getType() != User.Type.ORDINARY)
			throw new NotAcceptableException("Cannot set email address for service or ai user");
		else if (User.getLoginName(emailAddress.getValue()) != null)
			throw new NotAcceptableException("Email address with noreply domain is not allowed");
		else if (emailAddressService.findByValue(emailAddress.getValue()) != null)
			throw new NotAcceptableException("This email address is already used by another user");
		
		if (SecurityUtils.isAdministrator()) 
			emailAddress.setVerificationCode(null);
		
		emailAddressService.create(emailAddress);

		if (!getAuthUser().equals(owner)) 
			auditService.audit(null, "added email address \"" + emailAddress.getValue() + "\" in account \"" + owner.getName() + "\" via RESTful API", null, null);
		return emailAddress.getId();
	}
	
	@Api(order=250, description="Set as primary email address")
	@Path("/primary")
	@POST

View on GitHub (pinned to d44925c47c)

Solutions

1. Target an ORDINARY user account instead of a service or AI user
2. Remove service/AI users from the provisioning loop in scripts
3. Create a dedicated ordinary user if an email-bearing identity is genuinely needed

Example fix

// before
for (User u : users) createAddress(u); // includes service users
// after
for (User u : users) if (u.getType() == User.Type.ORDINARY) createAddress(u);

if (owner.getType() != User.Type.ORDINARY) skip;

boolean ordinary = owner != null && owner.getType() == User.Type.ORDINARY;

try { createEmailAddress(ea); } catch (NotAcceptableException e) { /* service/AI user: use ordinary account */ }

When it happens

Trigger: POST an EmailAddress whose owner's type is User.Type.SERVICE or AI instead of ORDINARY.

Common situations: Automation accidentally targeting a service account; scripting that iterates all users including service/AI users; confusing service accounts with regular robot user accounts.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• Reviewer not found:
• Assignee not found:
• Not authenticated
• Unauthorized
• Unauthorized

AI-assisted analysis of theonedev/onedev@d44925c47c (2026-09-06). Data as JSON: /api/errors/e52b43150a0c4918. Report an issue: GitHub.