Usually, the Studio framework will already have taken care of the login when your code is invoked.

In special cases, for example if you are not in CoreMedia Studio, you can use the static method com.coremedia.cap.Cap.prepare(Function) to create a connection to the remote server. The URL of the CMS remote service to use is read from the global variable coremediaRemoteServiceUri. The prepare method calls the callback function when the connection has been established, passing a com.coremedia.cap.common.CapConnection as the single argument. This connection is not yet bound to a user, but it provides the method getLoginService(). On the returned com.coremedia.cap.common.LoginService you can call the login(String, String, String, Function) method to authenticate the current user, which enables access to other services of the connection.

Once a connection is established, the current session is stored under the key session in the application scope bean (obtainable from the current editorContext instance). The session provides access to the current user and back to the connection.

The methods getContentRepository(), getUserRepository(), and getWorkflowRepository() of the connection return objects of type com.coremedia.cap.content.ContentRepository, com.coremedia.cap.user.UserRepository, and com.coremedia.cap.workflow.WorkflowRepository, respectively. These repositories serve the same purpose as the identically named objects of the Unified API. However, the supported functionality is limited to the use cases required for content editing.

The ContentRepository provides access to the PublicationService and the content AccessControl through the method getPublicationService() and getAccessControl(), respectively.

Unlike the Unified API, approval operations using the publication service also approve all folders on the path to a content. Publication is very similar to the Unified API counterpart, but withdrawals are performed in a single step without the need to successively set a mark, approve it, and publish the withdrawal.

The AccessControl class in the package com.coremedia.cap.content.authorization allows you to check whether certain operations on contents are permitted for the current user. Some methods like mayMove() and mayCreate() are provided for special cases, but most checks are made using the method mayPerform, which takes a Right enumeration value to indicate the intended operation.

All these methods track the dependencies and can be used from within a FunctionValueExpression, even though you cannot register change listeners directly.

The WorkflowRepository provides access to the WorklistService and the workflow AccessControl through the method getWorklistService() and getAccessControl(), respectively.

The WorklistService corresponds closely to the WorklistService of the Unified API. It provides access to all user-specific lists, but not the administration lists. In particular, you can retrieve the list of process definition that the current user may instantiate, the processes the user has created, but not started, the processes the user has created and started, the offered task and the accepted tasks. You can also obtain lists of tasks that encountered problems during their execution.

All these methods track the dependencies and can be used from within a FunctionValueExpression, even though you cannot register change listeners directly.

The AccessControl class in the package com.coremedia.cap.workflow.authorization allows you to check whether certain operations on workflow objects are permitted for the current user. The methods match the methods defined in the Unified API. While the rights are being retrieved, the methods will return undefined. Afterwards a Boolean value is answered. Note, however, that no changes of rights are propagated to the client. This is not normally a problem, because the built-in rights policies depend on the current user, only, and not on the workflow state.