| | |
|---|
TUK-19 | The form offers the new field control 'auto-complete' as an alternative to the 'dynamic list' control | As an administrator, I want to support the users with a dynamic list-like control that does not need a form scripting for preparing its data. Acceptance criteria: {field:<technical qualified name>} -> The value(s) of the specified field
For many values, a URL parameter is added for each value in their sequence.
The autocomplete service offers a 'query' parameter which gets the characters the user has typed into the input field. The new form field offers a dialog with the same feature set as given for dynamic list fields. After clicking on the symbol the complete data is loaded (maximum allowed?) and shown as: After getting the data once the form is opened the data is reused. flat value list: examples are Greek alphabet (plug-in: 'dummy') and Currency (plug-in: 'object-catalog' with parameters cat_objecttype=catcurrency&value=catcurrency.currencyiso&description=catcurrency.description) hierarchical list: Countries (plug-in: 'json-catalog' with parameters pathkey={mylist} supports single and multi-selection open: shows value/valuelocalized and optional description
If the user enters characters into the field an auto-complete list is offered in the same way as given for the dynamic list. Check whether we can do this: If the value attribute 'selectable' is set to 'false' the value is shown inactive in the selection dialog and can not be selected. Error handling: If the syntax of the attribute value is not correct an error is thrown: 'This field is not correctly configured. Please, inform your administrator.'/''Das Feld ist nicht korrekt konfiguriert. Bitte informieren Sie Ihren Administrator.' If the response of the client-service is not well: 'The received data are not correct. Please, inform your administrator.'/'Die erhaltenen Daten sind nicht korrekt. Bitte informieren Sie Ihren Administrator.' If the client-service responded with an error: 'The catalog data could not read. Please, inform your administrator.'/'Die Katalogdaten konnten nicht gelesen werden.'
The new field component is used in the context and saved search form. Summary and result list: start with only showing the technical value not the localized one -> later story
|
TUK-4217 | When dropping a file on the client the favorited folders and the last opened folders are offered as filing location as provided in the Outlook and Office Add-ins | As a user, I want to be able to select a favored folder or one of the most recently opened folders to determine the destination of my just-dropped files so that I don't have to open them first. Acceptance criteria: On the drop view the list of 'Favorites'/'Favoriten' and the 'Last opened folders'/'Zuletzt geöffnete Ordner' are offered. In the case of favorites, only the folders are offered on the user interface Below the current buttons for the locations the 'Favorites'/'Favoriten' and 'Last opened folders'/'Zuletzt geöffnete Ordner' are offered with an accordion control. The accordions are only shown if a folder exists. For the folder buttons, the icon of the relevant folder is shown for the favorites their title and the creation time for the last opened folders their title and description show 3 buttons and scroll for more
The collapsing status is remembered
|
TUK-4492 | The singing-service provides a new endpoint 'statistics' that show the count of signatures for a given document type, signature type, a range of time, aggregated by a given attribute | As an OS accounting member, I want to be supported by statistics concerning the processed signatures within a range of time differentiated by subsidiaries (e.g. a quartal) so that I can issue the invoice for each of the subsidiaries. Acceptance criteria: The signing-service offers an endpoint 'statistics' that reports the number of signings and affected documents for the following optional parameters documentTypes = a list of object types, default is none for all object types that are derived from yuvsigning status = list of values that are given by the catalog yuvsigstatus, default is 'signed', others are requested, inprocess, error, revised signatureType = list of values given by the catalog yuvsigtype: simple, advanced, qualified, default is all of them 'from' and 'to' = a time range, default is the first and last day of the year 'aggregationfield' = the Elasticsearch-specific name related to a qualified technical name of an object property or its context (parent) The signing-service requests Elasticsearch natively based on these parameters so that the aggregation of the table data for yuvsigners is supported.
The endpoint is FORBIDDEN for users without the role 'Use signature statistics' Documentatation can be read here: https://yuuvisdevelop.atlassian.net/wiki/spaces/onpremise/pages/447184897/General+Configurations+for+Signing#GET-http://%3Cgateway%3E/signing/statistics Instead of the search API the new Elasticsearch API is used.
- name: signingservice
type: microservice
profiles: prod,cloud,es
instances: 1
memory: 256M
....
|
TUK-4591 | The search API allows to search for objects that do not match the specified value for a property | As a programmer, I want to support users searching for objects that do not contain a specific value to find such and work with them. Acceptance criteria: filters":{
"qadocallfields.date1":{
"o":"eq",
"v1":"Wort",
"usenot": true
}
} |
TUK-4776 | The signing-service endpoints for status and refresh can only be requested by users with the privilege 'Manage system settings' | As an administrator, I want to be assured that non-admin users can not request the status endpoint. Acceptance criteria: |
TUK-5062 | An auto-complete plug-in for a hierarchical list based on a JSON file is available | As an administrator, I would like to get a hierarchical list from the auto-complete service which is set up by reading the data from my JSON file so that I can be offered to the user in the auto-complete selection dialog. Acceptance criteria: The plugin interface handles the language and the roles of the user. The JSON format for the hierarchical list is specified and aligned to the existing dynamic list. The 'json-catalog' plug-in example reads the catalog data from the JSON file during the start and handles the data in the RAM. The plug-in returns the values with their description and selectability regarding the given 'query' parameter, user language, and role. The plug-in is delivered with the installation including sample JSON files.
It is possible to configure the different JSON files in the client-prod.yml which can be used by this example plug-in.
|
TUK-5147 | If the lock of an object was released by a different user a history entry is written | As a system auditor, I want to see an audit entry if a document was unlocked by a different user to fit the compliance regulations of my company. Acceptance criteria: In this case, a history entry is written and the client shows:
EN: 'The lock was released.'
Description: 'The lock of {{lockusername{}}} was released by a privileged user.'
DE: 'Die Sperre wurde aufgehoben.'
Description: 'Die Sperre von {{lockusername{}}} wurde durch einen berechtigten Benutzer aufgehoben.' The executing user is protocolled
|
TUK-5239 | The widget 'Signature statistics' shows the number of signatures provided by the statistics endpoint in the signing-service | As an OS accounting member, I want to be supported by a widget that shows the signature statistics provided by the signing-service so that I configure my parameters easily. Acceptance criteria: |
TUK-5246 | It can be configured whether a document should be finalized after the signing process is finished and an info email is sent to the requester | As an administrator, I will be able to let the document be finalized when the signing process is finished regulations need this. Acceptance criteria: The signing-service can be configured to start a BPM process that finalizes a document at the end of the signing process as default, default is not to finalize. The service-manager installation writes the parameter into the signing-prod.yml (used in new installation but not "update"):
|
TUK-5289 | It can be configured whether an email is sent to the administrator in an error case during the signing-process | As an administrator, I will be informed about the error cases of the signing-service to analyze and correct the issue. Acceptance criteria: Inside the cyclic checking/processing of documents "in process" error can occur.
This can be errors affecting the whole check (no connection to signature provider, faulty configurations, ...) - in this case, the check stops, and an exception is logged -> if the "admin-email" is enabled, an email with this exception will be sent: If the error only affects single documents (wrong ID, workflow could not be started) these errors are also logged in the logfile (and collected during the current cycle of the check) -> if the "admin-email" is enabled, an email with a list of this problems will be sent: The email is only sent if the email functionality is configured properly in the core service. Disclaimer: The email is not sent for operations triggered by a user or admin. If a signing is requested and fails during the request or canceling and an error is returned, the admin is not bothered with an email.... Documentation is here: https://yuuvisdevelop.atlassian.net/wiki/spaces/onpremise/pages/447184897/General+Configurations+for+Signing#Error-notification-via-email
|
TUK-5316 | The search API supports the datetime search ranges tomorrow, nextweek, nextmonth, nextyear, thisquarter, lastquarter, nextquarter, last/nextnumberofdays/weeks/months/years | As a programmer, I want to support my users to search for objects with a date or datetime property to find for e.g. contracts that will expire in the next week or month, or the rententime that expires in the nextyear. Acceptance criteria: The search API range search for datetime properties is extended to tomorrow, nextweek (first day to last day of next week), nextmonth (first day to last day of next month), and next year (first day to last day of next year). Example:
|