MultiExcerpt Reporting Macro - summary overview of MultiExcerpts, their owner pages and includes
Add a multiexcerpt reporting macro that generates a table that displays the following columns:
The multiexcerpts residing in a space
The pages they are on
The pages that have Multiexcerpt Include macros that reference them
When the page was last updated.
This report macro could look similar to the Page Properties Report macro, with the columns being sortable.
Customer requested options for this macro are:
In Space: Accepts space keys, defaults to current space
Filter by Label: Accepts page labels, defaults to no filter
Columns to show: Drop-down list with choices
Page(s) with Multiexcerpt Include macro referencing the Multiexcerpt macro
Last updated (preferably when the content within the multiexcerpt was updated, vs. when the page was updated)
The cloud version of this request is at
Create a Support Ticket
Great! This description looks much like a housekeeping overview for space admins.
Let me add two things which came to my mind:
The similarity to the page property report initially intended to get a content table: a table of chosen multiexcerpt names displaying the content of these excerpts much like the page property report.
allow to use any cql-statement for filtering as different organisations use different data architectures. But as the page property report requires to use a label it forces me to somehow make sure that e.g. project pages always carry both: label and metadataset which is annoying as any user can remove one of them anytime…
For example we (DLR) heavily use metadatasets (from the Communardo Plugin) replacing labels which represent the type of content: Metadataset.project instead of labels named project, metadataset.glossary instead label glossary, etc. As metadatasets can hold certain metadatafields, defined attributes for each apge-content-type can be qualified: projects have descriptions, partners, cost units etc. and glossaries have translations, synonyms, abbreveations, target groups etc. The architecture behind is that labels should describe only topics while page-content-types in metadatasets deliver additional metadata structures relevant to the specific content. Target groups for the content and page-content-types should be defined in another way.