New features

Release 6.0.0

• Active and Historical Timelines UI
  Developers and admins now have the ability to centrally orchestrate common Continuous Data and developer operations from the DCT UI; this includes the ability to refresh, rewind, bookmark, and bookmark share (refresh to relative). This functionality also exposes the notion of time flows (non-active timelines), which is a critical tool for viewing past work on a VDB, such as the chronology of test results.
  
• Bookmark UI
  Developers and admins now have added visibility of bookmarks, both globally and contextualized, to individual VDBs. These visualizations are dual purpose; for administrators, these screens help with reporting and tagging on bookmarks, while for developers, these screens act as a catalog of actionable data references. 
  • Global bookmark list: View all bookmarks across your entire connected Delphix ecosystem. This screen will show bookmarks for both single VDBs and VDB groups.
  • VDB bookmark list: See all bookmarks tied to this individual VDB. This is helpful for sharing bookmarks with team members who have a compatible VDB (same parent and provision point). 
• Environment detail page improvements
  Users can now orchestrate common environment actions via the DCT UI. This includes enable, disable, environment refresh, and delete, as well as editing host details.
  Note

  Editing host details is only applicable to standalone environments at this time.
• Compliance job copy/execute UI
  Users can now orchestrate job movement and execution from the DCT UI. This functionality enables users to both orchestrate and report on the movement and execution of compliance jobs from the DCT UI. 
• Access visibility
  Object detail pages will include an access tab that provides visibility to user access and the associated permissions for each user. This is a critical enabler for permissions visibility and auditing.
• Copy/delete functionality on role scopes
  Scoped roles can now be copied and deleted within the DCT UI. This will enable easier administration, especially around the use of custom roles, as admins can now copy and modify new roles from templates. 
• External Postgres DB support
  DCT now supports the use of an external Postgres database to house DCT metadata. Previously, DCT supplied and managed its own database, requiring persistent storage within the container platform.  

Release 5.0.1

Enhancements

• Data scoped Access Group
  • Enhancement in Roles
    Associated permissions in roles are changed from 'string' type to 'permission object' type. For details, see the Role schema in the API References.
  • Custom Roles
    In addition to the 5 pre-seeded fixed roles (Admin, Monitoring, DevOps, Masking, and Owner), DCT provides flexibility to create new custom roles as per user need. Users (Accounts) can create new custom roles by encapsulating any combination of permissions. The custom roles can be configured through a UI configuration screen (screenshot below), in addition to a set of APIs to manage roles. For details, see the API References.
    
• Updates to existing RBAC model
  For better usability and allow to set more granular permissions there are following enhancements in the RBAC model: 
  • Renamed Access Group "Policy" to Access Group "Scope"
  • Renamed the following APIs related to Access Group actions
    • Add scope to an Access Group
      POST: /access-groups/{accessGroupId}/policies → POST /access-groups/{accessGroupId}/scopes
    • Remove scope from Access Group
      DELETE /access-groups/{accessGroupId}/policies/{policyId} → DELETE /access-groups/{accessGroupId}/scopes/{scopeId}
    • Get Access Group scope
      GET /access-groups/{accessGroupId}/policies/{policyId} → GET /access-groups/{accessGroupId}/scopes/{scopeId}
    • Update Access Group scope
      PATCH /access-groups/{accessGroupId}/policies/{policyId} → PATCH /access-groups/{accessGroupId}/scopes/{scopeId}
    • Add object tags to Access Group scope
      POST /access-groups/{accessGroupId}/policies/{policyId}/object-tags → POST /access-groups/{accessGroupId}/scopes/{scopeId}/object-tags
    • Remove object tags from Access Group scope
      POST /access-groups/{accessGroupId}/policies/{policyId}/object-tags/delete → POST /access-groups/{accessGroupId}/scopes/{scopeId}/object-tags/delete
    • Add objects to Access Group scope
      POST /access-groups/{accessGroupId}/policies/{policyId}/objects → POST /access-groups/{accessGroupId}/scopes/{scopeId}/objects
    • Remove objects from Access Groups scope
      POST /access-groups/{accessGroupId}/policies/{policyId}/objects/delete → POST /access-groups/{accessGroupId}/scopes/{scopeId}/objects/delete
  • Renamed the "everything" flag to "scope_type"
    In order to make it more understandable, we have renamed the everything flag to scope_type. There are three possible values for scope_type i.e. SIMPLE, SCOPED and ADVANCED. The value SIMPLE corresponds to everything=true and SCOPED corresponds to everything=false. The value ADVANCED for scope_type is new enhancement to setting permissions which allows users to set permissions (e.g. READ, DELETE) for an object. There is more information about ADVANCED scope in next section.
  • Access Group Scope: Advanced scope type
    In Add objects to access group scope API, now user can define permissions level checks as well for an object. For example, earlier when object_id and and object_type are provided in request payload, all permissions that are defined in scope are applied to this object. But now user can define specific permissions.
    
    API Example:
    curl --location --request POST '<hostname>/v3/access-groups/{access-group-id}/scopes/{scopeId}/objects' \ 

    --header 'Content-Type: application/json' \

    --data-raw '{

        "objects": [

            {

                "object_id": "1",

                "object_type": "ACCOUNT",

                "permission" : "READ"

            }

        ]}'

  • Add an always allowed object to Access Group scope
    Always allowed objects can be defined as objects that are always allowed for an access group scope. This can be set as follows:
    
    Add always allowed objects:
    curl --location --request POST '<hostname>/v3/access-groups/{access-group-id}/scopes/{scope-id}/always_allowed_permissions' \--header 'Content-Type: application/json' \
--data-raw '{
    "always_allowed_permissions": [
        {
            "object_type": "ACCOUNT",
            "permission" : "READ"
        }
    ]
}'
Response: The updated access group scope
    
    Here it means that all objects with object type ACCOUNT and permission READ are allowed with this access group scope. This will clear out matching object type and permissions, if any in objects attribute of access group scope.
    
    Remove always allowed objects:
    curl --location --request POST '<hostname>/v3/access-groups/{access-group-id}/scopes/{scope-id}/always_allowed_permissions/delete' \--header 'Content-Type: application/json' \
--data-raw '{
    "always_allowed_permissions": [
        {
            "object_type": "ACCOUNT",
            "permission" : "READ"
        }
    ]
}'
Response: The updated access group scope
• Masking Jobs
  • CRUD APIs, COPY, Connectors CRUD
• Masking Job Execution
  • Connector Credentials
  • Execution API

Custom Roles

• Accounts can create new instances of role encapsulating any combination of permission.
• Role name must be unique.
• Custom roles can be updated. Accounts can add or remove permissions to/from the custom roles.
• Custom roles can be deleted. (If they are not associated with any Access Group).

Release 4.0

• Environment Overview List
• Un-virtualized Source Sizing Report
• Global VDB Templates
• Scoped Access Control

UI

• LDAP/AD and SAML/SSO Configuration UI

Release 3.0

• APIs
• Cluster Node (RAC) management APIs
• Ability to disable username/password authentication globally
• LDAP/Active Directory groups
• CDBs/vCDBs APIs
• VDB Provisioning / update for EDSI (AppData) platforms

UI

• Engine registration wizard
• Access Groups
• Compliance engine page

Release 2.2

Deployment

• Introducing Kubernetes and OpenShift support

APIs

• Registration of Continuous Compliance Engines
• Masking Connectors
• “Move Masking Job”
• Masking of mainframe objects
• Provisioning enhancements for Oracle multi-tenant and RAC
• LDAP/Active Directory authentication
• Password management
• Initial access management by Permissions, Roles, Policies, and Access Groups (permissions applied to all objects of a type e.g. Stop VDB permission on all VDBs)
• Distributed tracing and logging (Trace ID propagated down call stack)
• Bulk delete of tags

UI

• Continuous Data
  • Added tag support to the Infrastructure page
  • New dSources page
  • New VDBs page
• Insights
  • Added an export behavior to the Storage Summary report
  • New dSource Inventory report
  • New VDB Inventory report
• Admin
  • New Accounts page