@CurrentUser

[lukasj]

New annotation "@currentuser" should inject the current user into a data field (this is what databases do with the CURRENT USER constraint).

As in the Java EE environment there is a difference between security principals, business layer people, and database accounts, there should be a mapping available. For example "@currentuser(type = PRINCIPAL_NAME) String createdBy" would default the content of "createdBy" to the name of the caller principal's name. This is the most common need for automatic values in business applications.

[lukasj]

@glassfishrobot Commented
Reported by mkarg

[lukasj]

@glassfishrobot Commented
Parent-Task: JPA_SPEC-36

[lukasj]

@glassfishrobot Commented
@arjantijms said:
I wonder if something akin to @currentuser should not also, or perhaps first, be available for the entire Java EE platform.

[lukasj]

@glassfishrobot Commented
mkarg said:
Arjan, you can inject the current security principal into any CDI beand and EJB. So you have that there already. My proposal is focused on JPA because you cannot inject the security principal into a JPA entity.

[lukasj]

@glassfishrobot Commented
rbygrave said:
I don't think @currentuser is sufficient. That is, I think it is more common from an auditing perspective to require "who created" and "who modified" so instead have 2 annotations like:
@Whocreated
@WhoModified

Background:
These are the 2 annotations that we have in Ebean ORM which also has support for SQL 2011 history / temporal features ... "AS OF" queries and "BETWEEN VERSIONS" queries. Having both the user who created a row/object and user who last modified the row/object is not absolutely required once you have full SQL 2011 history support but I'd suggest it is a fairly common requirement otherwise. (So commonly there are 4 properties - @Whocreated, @WhoModified, @WhenCreated, @WhenModified)

[lukasj]

@glassfishrobot Commented
neilstockton said:
How does a plain JPA provider know what is the "current user"? In JavaSE there is no "user". Define where this is populated from

[lukasj]

@glassfishrobot Commented
rbygrave said:

now what is the "current user"?

There would also be an interface that is implemented (and registered with the JPA provider / EntityManagerFactory).

For me this looks like:

/**
 * Provides the current user in order to support 'Who created', 'Who modified' and other audit features.
 */
public interface CurrentUserProvider {

  /**
   * Return the current user id.
   * <p>
   * The type returned should match the type of the properties annotated
   * with @WhoCreated and @WhoModified. These are typically String, Long or UUID.
   * </p>
   */
  Object currentUser();
}

[lukasj]

@glassfishrobot Commented
rbygrave said:
As a side node, I'd expect that Multi-Tenancy would need a similar CurrentTenantProvider interface.

[lukasj]

@glassfishrobot Commented
This issue was imported from java.net JIRA JPA_SPEC-48

[lukasj]

@andyjefferson Commented
FWIW, DataNucleus implements this as 2 new annotations @CreateUser and @UpdateUser with the same interface proposed by rbygrave for CurrentUserProvider, with an instance of the provider being supplied via a persistence property.

[lukasj]

• Issue Imported From: https://github.com/javaee/jpa-spec/issues/48
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @ldemichiel

[gavinking]

Nailing down the semantics of this thing seems like an almost impossible task. You have:

• the principal defined by the EE security layer,
• the database current_user,
• the tenant id in a multi-tenant database, and
• maybe even something else if you have a full-blown audit/historical data system.

Which of those things are we talking about here? How is there any hope of reaching agreement on that?

I would say this doesn't belong in the spec.

[arjantijms]

I agree this doesn't belong in the current proposal in the Persistence spec. "@Inject Principal" for the EE Security layer is defined for all CDI beans, and if this one if needed something like a service or Entity listener classes can be injected with that and set it in the JPA entity.

[gavinking]

Yeah, injecting the Principal into an entity listener sounds like a fine solution for now.

And if/when we do #342 and #113, users will be able to easily write their own @CurrentUser annotations that do exactly the thing they need in their programs.

I'm going to close this.