Data center change requests

A typical scenario:

1. A user creates a change request, and fills in the form. The change request can be saved as Draft.
2. A Draft or a newly created request can be Submitted if all fields are filled in according to the validation specified in the form.
3. The Submitted request is read-only and waits for an Administrator to act. The request can be Unsubmitted by the author if some corrections need to be done, which puts it back into Draft.
4. The Administrator can do one of three operations on a Submitted change request:
   • Approve: The Administrator has accepted and processed the request, for example, by creating a work order for executing the change.
   • Reject: Indicates the change is impossible to complete.
   • Require more information: The request status is changed to Need update. The author can modify the form data and resubmit the request.
5. Approved request can be Closed by the Administrator.
6. After that request can then be deleted by the author or the Administrator. 

Requests in Draft state are only visible to the author; they are not visible to other users.

Requests in other states are visible only to the author and Administrators.

If the author of a request is removed from the system, requests in Draft and Needs Update states are deleted. Requests in Submitted, Rejected, and Approved states survive so administrators can act on them.

You can comment on requests in states other than Draft to allow further communication between the author and the administrator.

When a request changes state, or a comment is posted, a notification email is sent to interested parties:

1. If the change or comment is made by the author of the request, email is sent to all administrators.
2. If the change or comment is made by an administrator, email is sent to the author of the request.

Email is sent in the user’s preferred language.

Note: You must configure mail settings with the Mail configuration REST web service.

Creating, deleting and changing the request state is logged in the Audit log. You can run a report in the desktop client to view the audit log.

Validation related to creating equipment using Change Requests

In order to use Change Request for equipment creation it has to be validated

What actions trigger validation?

Validation is triggered by following actions:

• Submitting request
• Accepting request
• Creating equipment based on request

What validation levels we define?

• Warning - will allow action to complete (eg. submit request). Yellow color in web client.
• Error - will not allow action to complete. Red color in web client

What kind of validators we define?

• Barcode validator - Checks if every barcode set in genome selector is unique. This will not be validated if genome selector do not use barcode or barcode is empty.
• Genome type validator - not every product from custom catalog that can be selected in genome selector can be used for equipment creation. List of illegal product types:
  • Breaker
  • Breaker module
  • Door
  • Perforated tile
  • Hacs
  • Cacs
  • Vertical Grille
  • Window
  • Wall
  • Gap
  • Water tank
  • Block
  • Person
• Custom property validators - used to validate mapping between form fields and custom property definitions. Form field is matched with custom property definition if it has the same label.

  • Custom property type validator - checks if form field type and custom property type are matching.

    Form field type	Custom property type
    Text	String
    Number	Integer, Decimal, String
    Email	Email
    Location	String
    Radio	String
    Select	String

  • Custom property mandatoriness validator - checks if form field value was set when custom property definition is marked as mandatory.

  • Custom property uniqueness validator - checks if form field value is unique among all equipment when custom property definition is marked as unique
  • Custom property value validator - checks if form field value is correct depending on custom property type.

What validator is being run on particular action?