Intention
This tip lists different best practices how we are managing certain administrative use cases within Integrity LM. All of them are in production since some years, and very stable.
Status
The list below is a working list. Feel free to comment or even add more. I will update the main tip section accordingly.
Best Practices with Use Cases
Topics #1 to #10 are here
Topic #11
- Item Editability Restriction
Use Case
- As a process responsible, I want to make sure that only specific persons are allowed to edit items.
- As a process responsible, I want to assign the current user as default value for "Assigned User", that any item has a value in this field.
- As a process responsible, I want to make sure that users assigned to a read-only group can not edit any item in Integrity.
- As a process responsible, I want to allow that Project Administrators and Team Leads can always edit an item.
Best Practice
- Add the field "Assigned User" to any item type of interest
- Create a trigger which assigns the current user as "Assigned User" if not set.
- Create a static and also a dynamic group to handle Read Only permissions
- Create an Item Editability rule for each item type, like the following:
Topic #12
- Effective Role Management: Object Access Roles
Use Case
- As an process responsible, I like to make sure, that a user will see only the relevant objects for a his role, such as specific types, specific queries, specific reports, specific charts.
Best Practice
- A common practice is to create so called Object Access Groups. Such a static group will bundle role specific types, queries, reports, charts etc.
- For example, such a role might be named "ROLE_Req_OBJ", and will contain all objects needed to fulfill requirement tasks. Another will be named "ROLE_Test_Mgr_OBJ". This role will contain only test management related objects.
- When adding a new user and granting a User Role, the user will get a business role such as "Requirement Manager" and also this related Object Role, such as ROLE_Req_OBJ.
- When a new Report gets created for Requirement Managers, then the report gets assigned to the ROLE_Req_OBJ role, and immediately all Requirement Managers will see that report, but only by them.
Example
Topic #13
- Special Projects
Use Case
- As a project responsible, I want to have the following special projects: Library, Templates, Trash
Best Practices
- Create a "Library" project that holds common objects, such as Abbreviation Documents, or reusable Test Steps.
- You can use the tip #8 to prevent the user from putting something into this library project that you don't want to have as a library element.
- Create a "Template" project that holds templates for documents, or even items.
- You can use the tip #8 to prevent the user from putting something into this folder that you don't want to have as a template.
- Create a "Trash" project, into which a user or team lead can drop a no-more-needed document.
- You can use a trigger to prevent that someone can drop a document with traces in it.
- You can use the tip #8 to prevent the user from dropping something that should never be dropped.
- You may schedule a purge process for automated purging.
- You may restrict this Trash folder visibility to Team Leads only.
- Each of the mentioned special projects can be team specific or global. Usually, we create different of them depening on the collaboration processes in place.
Topic #14
- Tracing and Trace Definition
Use Case
- As a user, I want that the system helps me to define the right traces.
- As a user, I want that the system avoids creating traces to Headings and Comments.
- As an administrator, I want an easy way to define the Alt-drag-drop functionality.
Best Practices
- When defining the Alt-drag-drop functionality for Tracing, always include the category. This would avoid that someone creates traces between Headings, or Comments.
- Activate a trigger that checks about any invalid tracing that a user might perform in the relationship fields itself. Again, check that only meaningful nodes will be traced.
- Use the Trace Manager App to define and review the trace definition easily.
- Use the Trace Manager App to create automatically the corresponding STeF tests. (see topic #10)
Topic #15
- Dashboard Alternative with external Data
Use Case
- As a Project Manager, I want to have an overview about my project, where some data are from Integrity itself, whereas other data are provided by other systems.
Best Practices
- There are many ways to handle this. My suggestion is to use a report, and feed external data into the report using JSON and/or JSP.
- A JSP can also display data provided in XML files. If such an XML file contains the data provided by the external tool, then our report and/or dashboard can display local and remote data in parallel.
- If the build in capabilities for charts are not enougt, consider the use of modern JavaScript libraries where you can create almost any chart type.
Topic #16
- Standardized Custom Trigger Logging
Use Case
- As a System Responsible, I want to get a standardized and consistent Trigger logging spooled to the server.log
Best Practice
- Develop a Trigger Framework, in Java, to standardize the Custom Trigger logging.
- Possible output might look like this:
-
Topic #17
- Standartized Reminder e-Mails
Use Case
- As a User, I want to receive reminder e-Mails about upcoming deadlines, or already missed deadlines.
Best Practice
- Implement a new Item Type which holds the definition and the rules of how and when a reminder shall be send out.
- Define a Trigger which reads the reminder definition, and sends out the email according to the defined reminder cycle.
- Plan how you track the items you already reminded. Store also a log file.
Topic #18
- Custom Help System
Use Case
- As a User, I want to have the possibility to access context - means type specific - specific help right out of the UI.
Best Practice
- Adapt the Presentation Template and add another link to a type specific html page.
- This help page might be generated, with links in it to different other information sources, such as team help pages outside (e.g. sharepoint, standard help, templates, process descriptions etc.)
- We manage the links directly in a new item type.
-
Topic #19
- Scheduled Trigger Chart
Use Case
- As a system owner, I want to get an overview about the Triggers ran easily.
Best Practice
- Use a Trigger Framework to track the start and end time of triggers.
- Take those data and store them in a new tracking item type.
- Use standard build-in Charting tool to present the details of which scheduled trigger fired when.
Topic #20
- Validate any system configuration frequently
Use Case
- As a system owner, I want to get automated support to check my own configuration rules.
Best Practice
- Use the Trigger Framework to define multiple validation tasks to check your configuration
- Define for each validation a single JavaScript file
- Execute the validations using dynamic script inclusion.
- Send an email about the validation results to the system owner daily.
-
More to come 🙂
