Details
-
New Feature
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
None
-
None
Description
The new service will be exposed as a new Hippo Services API and a separate implementation module which will be initialized as a daemon module.
The service will automatically 'reload' the model on document type and/or repository node type changes, so the meta-data exposed will be 'current' with the latest (committed) document types and repository model
Attachments
Issue Links
- relates to
-
CMS-7070 Store additional mixins added through the DocumentType Editor in a separate (new) mixins property instead of the supertypes property
- Open
-
CMS-7096 In the DocumentType Editor a document field doesn't have an consistent logical name except for its low-level JCR Item name or its caption which should be localizable
- Open
-
CMS-7189 Improve handling of possible intermediate errors during ContentTypeService model loading
- Open
-
CMS-7190 Add i18n support to ContentType service
- Open
-
CMS-7060 The DocumentType model is unaware of hippo:harddocument while it is used and needed on all prototypes
- Closed
-
CMS-7205 Provide a new generalized Content Service and API using the dynamic ContentType Service model
- Open
-
CMS-7203 Add query and versioning related meta-data to ContentType Model
- Closed
- waits for
-
CMS-6940 Removal of field in Document type editor is immediately effective in a Document Editor for that type, before the removal is committed
- Open
-
CMS-7044 Document type field specific 'constraints' like height or width for a Html field should be stored with the field definition itself (workflow capable) and not in the editor template (not workflow capable)
- Open
-
CMS-7064 DocumentTypeEditor doesn't retain mixins on a base type when creating a new type extending that base type
- Open
-
CMS-7065 The DocumentTypeEditor allows changing the path of a hippstd:taggable tags mixin property within a document type thereby changing the path within the hippostd:taggable mixin itself
- Open
-
CMS-7066 DocumentType configurations for Mixins like taxonomy:classifiable are stored in an opaque manner which cannot be deducted from the repository alone
- Open
-
CMS-7067 An extended document type created by the DocumentType Editor doesn't (automatically) inherit fields from its base type which you would expect from the logical model
- Open
-
CMS-7068 In the DocumentType Editor setting an inherited String property to required changes the (live) property definition in its base type
- Open
-
CMS-7097 CMS Validators store configuration outside the context of Document Type definitions depending on them and without versioning like them
- Open