Papyrus Model Repository Administration

The previous article in this series, like so many before it, was all about features for end-users working collaboratively on models in Papyrus with CDO. Today, we turn our attention to the administrative user, that individual who is reponsible for providing the resources that everybody else needs to do their work.

Today's M3 milestone of the Luna release of CDO and Papyrus adds several new enhancements targeting primarily administrative users.

Password Management

In the Kepler release, CDO introduced a new security manager driven by a model of users, roles, and permissions. User identities and credentials are managed in the security model, although passwords are never exposed to clients. Nobody, not even the Administrator, has access to them. Authentication of user passwords is established by a server-initiated challenge to which the client replies an encrypted password response using a key determined by a secure key-agreement protocol.

The Luna M3 milestone adds two new password management functions:

• change password: on any manifestation of a CDO session (in the CDO Sessions view or a connected repository in the Papyrus Model Repositories view) that has a logged-in user ID, a new Change Password action lets the user change its password in the usual way. Note that repositories are not required to have a security manager installed; in these cases, there are no user IDs, so this action is not available
• reset password: in the case that a user has forgotten its password, an Administrator can invoke a new action in the security model editor to reset the user's password. A randomly generated new password is presented to the Administrator to share with the user

Security Model Editor

The standard reflective tree editor is sufficient for managing the security model, but it isn't as efficient as it might be for the most common (80% rule) use cases. Lots of right-clicking and jumping back and forth between the editor and Properties view is required to add users, groups, permissions, and especially associations between the various elements.

To stream-line the basic scenario of defining users, groups, and resource-based access rules, a new form editor provides

• convenient presentation of groups, users, and roles in a master/detail structure
• access to the essential properties of objects right in the details pane of the editor
• intuitive drag-and-drop gestures for associating users, groups, and roles
• simple definition of resource-path-based permissions for roles

Security Model Integrity Checks

The security model is "just" an EMF-based model, so you can do pretty much anything with it, including shoot yourself in the proverbial foot. New in M3 is server-side validation of any transaction that modifies the security model to reject two kinds of change that would break the security manager:

• inheritance cycles in groups: users are implicitly assigned the roles of the groups that they are members of and all groups that those inherit. Inheritance cycles could lead to recursion errors
• inaccessible security model: the server rejects any transaction that would result in no users having administrative access, that is, write access to the security model

Both the reflective tree editor and the dedicated security form editor detect and report transactions rejected by the server, with a message describing the integrity violation.

Remote Repository Administration

The Kepler release of CDO added a CDO Administration view that lets users open an administrative interface to a CDO server to monitor the status of the repositories that it hosts. However, although there was a protocol and API for effecting changes to the server such as creating and deleting repositories, this was unimplemented in the server and not exposed in the UI.

The M3 milestone introduces a new "administrative repository" concept to implement the create/delete repository functions. This repository provides two key components:

• an administrator user role (per the usual security model) that serves as a server-wide administrator to authorize remote administration operations
• a catalog of repositories that were dynamically added via the administrative interface (they are not maintained in the cdo-server.xml file)

A new app extension in the server loads the repository catalog to start the repositories that it defines. On the client side, a new Create Repository wizard and Delete Repository action allow a suitably-authorized user to remotely direct the creation and removal of repositories in the server.

Currently, the deletion function merely stops the repository and removes it from the catalog. Actually dropping a database, for example, is a much more significant action (losing lots of data!) and is left for administrators to manage in ad hoc fashion according to their needs. The important point is that it makes the repository unavailable to connected clients.

The creation wizard currently supports only the most commonly used repository properties and the H2 database store, though it is designed with extensibility in mind to support other store types (contributions are welcome!).

The video embedded above provides a short demonstration of most of these new features. For additional details and discussion, see Bug 415375, especially its dependencies and their associated Gerrit reviews.

Finally, be aware that there are a few glitches in some of these functions in the "official" Luna M3 milestone. The first weekly integration builds of CDO and Papyrus following M3 will have fixes for those that are known so far.

Link to Documents in Papyrus Model Repositories

Last time, we looked at searching for stuff in your Papyrus model repositories. What is better than searching for models and documents? Linking to them so that you don't have to search again.

The Kepler release of Papyrus has a facility for creating hyperlinks from shapes in diagrams to arbitrary documents in the local filesystem or anywhere on the Internet that is addressable by a URL. This is updated in the upcoming M2 milestone of the Luna release to support hyperlinking to documents in CDO model repositories. That's right, documents in model repositories. The Kepler release of CDO added support for storage of "file resources", text or binary, as CLOBs and BLOBs, respectively, in the database. As usual, I have recorded a short video demonstration of this new feature in action.

A brief demonstration of a new feature in Eclipse Papyrus M2 of the Luna release: hyperlinking to documents in CDO model repositories.

In brief, Luna M2 will have:

• the Model Repositories view now shows all resources in your repository, including non-Papyrus models and file resources. You can create and edit file resources in this view
• a refactored hyperlink dialog: all the different types of hyperlinks are now managed in a single tab, not in separate tabs
• in the hyperlink dialog, browse currently connected repositories to select a file resource ("document") or even a Papyrus model to link
• drag-and-drop documents and models from the Model Repositories view to a shape in a diagram to create hyperlinks
• create hyperlinks (by browse or drag-and-drop) to resources in a repository from models in other repositories or the workspace
• click a hyperlink in the pop-up action bar to open the linked document or model in the appropriate editor, opening the connection to the repository first, if necessary

See bug 415373 for the further details.

Search Your Model Repositories

The first new feature of CDO model repository integration in the Luna release of Papyrus has landed: model search.

As usual, I have recorded a short video demonstrating this new feature.

In the Kepler release, Papyrus added text-based and OCL-based searching of models in the Papyrus Search tab of the Eclipse Search dialog. Naturally, this only covered searching models in the workspace.

Now, with the latest nightly build of Papyrus and the latest integration build of CDO (yes, both are required!), you can start searching models in your repository by matching substrings or regular expressions (case-insensitive or not) against:

• element name
• all string-valued attributes of each element
• specific attributes (string-valued or not) of specific kinds of elements — the "Advanced" mode

Searches can be scoped to:

• the workspace: all currently connected repositories, including all open projects in the local workspace
• the selection: selected repositories, folders, and models in the Model Repositories view

Search results are shown as usual in the Search view and expand to show how individual attributes matched. Double-clicking a search result navigates to that element in the model, opening it in an editor first, if necessary. When a repository connection is closed, all search results from that repository are purged from the Search view.

Searches are implemented using CDO's awesome server-side OCL query capability, by generating OCL query expressions based on the search criteria specified by the user in the UI. CDO's OCL support was already pretty awesome in the Kepler release, but it is made even awesomer by a couple of new enhancements in Luna implemented to assist applications like Papyrus:

• using CDO's standard query parameter API it is now possible to specify an implicit root EClass for objects. This is often used to make the operations defined by EObject easily accessible in your OCL expresions — cf. bug 416366
• the OCL environment in the CDO server now provides two additional operations on the OclAny class to simplify querying — cf. bug 416474
  • cdoAllProperContents(OclType) — gathers all instances of a given type within a resource as a collection of that type
  • cdoMatches(String) — efficiently determines whether any string attribute of an object matches a regular expression

Download a build (you will need CDO, the Papyrus main build, and the CDO integration feature from the "Papyrus Extra" build) and start searching! Or wait for M2 of the Luna Modeling package if you're patient. See bug 415371 for details.