Reports pack
Most of these reports are based on the Activity log events audit trail.
For more information Activity log.
Template reports
Name | Use Activity log | Require parameters | Description |
---|---|---|---|
JavaReportPattern.jrxml |
No. |
No. |
Template pattern that uses Java to retrieve data. |
No. |
No. |
Template pattern that uses SQL to retrieve data. |
|
No. |
No. |
Subreport sample. Support for subreports is available starting from version 8.1.15. |
Authentication
Name | Use Activity log | Require parameters | Description |
---|---|---|---|
UsersLogin.rep |
Yes. |
Yes. |
User logins, filtered by date range. |
Yes. |
Yes. |
User logouts, filtered by date range. |
|
Yes. |
Yes. |
Users whose sessions expired, filtered by date range. |
Documents
Name | Use Activity log | Require parameters | Description |
---|---|---|---|
Yes. |
Yes. |
Lists documents that cancelled the edition, filtered by date range. |
|
DocumentCheckin.rep |
Yes. |
Yes. |
Lists documents updated, filtered by date range. |
Yes. |
Yes. |
Lists documents being edited, filtered by date range. |
|
Yes. |
Yes. |
Lists documents created, filtered by date range. |
|
Yes. |
Yes. |
Lists documents deleted, filtered by date range. |
|
Yes. |
Yes. |
Shows when users listed documents in a folder or record. Results are filtered by date range. To list documents in a folder, an internal method named "getChildren" is called. |
|
Yes. |
Yes. |
Shows when users retrieved the content of a document. Results are filtered by date range. For example, when a user downloads or previews a document (among other actions), they are retrieving the document's content. |
|
Yes. |
Yes. |
Shows when users retrieved a specific version of a document's content. Results are filtered by date range. |
|
Yes. |
Yes. |
Shows when a user retrieved the properties of a document. Results are filtered by date range. For example, when a document is selected, an internal method named "getProperties" is called to fill the contents of the properties tab in the user interface. |
|
Yes. |
Yes. |
Shown when users retrieve the list of all versions of a document. Results are filtered by date range. |
|
Yes. |
Yes. |
Lists when the fields of a metadata group have been retrieved. For example, when a metadata group is shown in the user interface, an internal method named "getPropertyGroupProperties" is called to fill the metadata group values. |
|
Yes. |
Yes. |
Lists documents updated, filtered by date range. |
|
Yes. |
Yes. |
Lists documents moved, filtered by date range. |
|
Yes. |
Yes. |
Lists documents purged, filtered by date range. When a document is purged, it will permanently disappear from the application repository. |
|
Yes. |
Yes. |
Lists documents renamed, filtered by date range. |
|
Yes. |
Yes. |
Lists documents unlocked, filtered by date range. |
|
No. |
No. |
Retrieves a list of available documents (security filtered) ordered by folder name. Optimized for CSV format. Not recommended for large repositories; it can take a lot of time. |
|
DuplicatedFiles-v-7.1.23.jrxml | No. | No. |
This report can only be used for version 7.1.23 or higher. List of duplicated files in the application repository, based on document checksum. |
No. |
No. |
This report only can be used for version 7.1.22 or lower. List of duplicated files in the application repository, based on document checksum. |
|
No. |
Yes. |
List of all documents in some folders and subfolders with checksum values. |
Folders
Name | Use Activity log | Require parameters | Description |
---|---|---|---|
Yes. |
Yes. |
Lists folders copied, filtered by date range. |
|
Yes. |
Yes. |
Lists folders created, filtered by date range. |
|
Yes. |
Yes. |
Lists folders deleted, filtered by date range. |
|
Yes. |
Yes. |
Shows when users listed folders in a folder or record. Results are filtered by date range. To list folders in a folder, an internal method named "getChildren" is called. |
|
Yes. |
Yes. |
Shown when the internal method named "getContentInfo" has been executed. To perform some operations, it is necessary to calculate folder depth, for example before starting a folder ZIP download. There's an internal method named "getContentInfo" that does it. |
|
Yes. |
Yes. |
Shows when a user retrieved the properties of a folder. Results are filtered by date range. For example, when a folder is selected, an internal method named "getProperties" is called to fill the contents of the properties tab in the user interface. |
|
Yes. |
Yes. |
List folders moved, filtered by date range. |
|
Yes. |
Yes. |
List folders purged, filtered by date range. When a folder is purged it will definitively disappear from application repository. |
|
Yes. |
Yes. |
List folders renamed, filtered by date range. |
|
No. |
Yes. |
Lists folders and subfolders showing security regarding roles and/or users. | |
No. |
Yes. |
Lists folders and subfolders showing the size of each one. |
Mails
Name | Use Activity log | Require parameters | Description |
---|---|---|---|
Yes. |
Yes. |
Lists mails created, filtered by date range. |
|
MailGetProperties.rep |
Yes. |
Yes. |
Shown when a user retrieves the properties of a mail. Results are filtered by date range. For example, when a mail is selected, an internal method named "getProperties" is called to fill the contents of the properties tab in the user interface. |
Yes. |
Yes. |
Lists mails purged, filtered by date range. When a mail is purged, it will permanently disappear from the application repository. |
|
Yes. |
Yes. |
Lists mails renamed, filtered by date range. |
|
Yes. |
Yes. |
Lists mails moved, filtered by date range. |
|
Yes. |
Yes. |
Lists mails copied, filtered by date range. |
|
Yes. |
Yes. |
Shows when users listed mails in a folder or record. Results are filtered by date range. To list mails in a folder, an internal method named "getChildren" is called. |
Others
Name | Use Activity log | Require parameters | Description |
---|---|---|---|
No. |
No. |
Document size (in MB) by user and tenant. |
|
No. |
No. |
Each workflow task with the time spent on it. |
|
No. |
No. |
Registered users. |
Subreports
Restrictions:
-
The name of the subreport must always start with "subreport-", for example, subreport-roles.jrxml.
-
In the main report, you must create a parameter with the same name as the subreport (without the extension). For example, if the subreport is named subreport-roles.jrxml, the parameter should be named subreport-roles, and the associated class should be net.sf.jasperreports.engine.JasperReport.
-
The expression in the subreport must correspond to the value of the created parameter. Following the example from the previous point, it should be $P{subreport-roles}.
- Both reports must share the same database connection.
XML sections sample
In the main JRXML, define the subreport parameter:
<parameter name="subreport-roles" class="net.sf.jasperreports.engine.JasperReport"/>
Then in the subreport element, use the parameter reference:
<subreport>
<reportElement x="0" y="0" width="200" height="100"/>
<subreportExpression><![CDATA[$P{subreport-roles}]]></subreportExpression>
</subreport>
The key points are:
- The parameter name must match the filename without the extension used in the REP (ZIP file).
- Parameter type must be JasperReport.
- Use $P{parameter-name} in subreportExpression.
- Remove any file path references from subreportExpression.
How it works in the background:
- The OpenKM core loads the subreport from the REP (ZIP file).
- It adds it to the params map with the correct name.
- JasperReports finds it via the parameter reference instead of a file path.
Screenshots
Subreport parameter
Subreport expression
Suggestions during development
The dynamic configuration of subreports through parameters will work once the report is deployed in OpenKM, but it will not work in the Jasper Studio application. On the other hand, configuring subreports with file system paths will work in Jasper Studio but will likely not work in OpenKM (we do not recommend using paths).
During development, you will likely want to test the report from the Jasper Studio application before deploying it to production. For this reason, we recommend setting the report path directly (file system path) during this phase of development, and once completed, modify it to use dynamic access via the parameter mentioned earlier.