The Request type in Virtual Ticket currently supports the following:
Request Intake Form
This form can be customized to show two subforms
- Any subform/viewModel specified through the customRequestForm observable
- A subform specified by the current Request Type (i.e. Requests with type "Job Request" will load the Job Request subform under Requests)
If you would like to use the Request Intake form then you can customize the client specific file called request_info_custom.js
The FormViewModel extends the RequestViewModel, which sets up the observables and a handy function to transfer data from the Request to the Job.
RequestViewModel - Options
Within the RequestViewModel there are several observables connected with the way things are displayed on the form.
Observable Name | Value Type | Associated Action/Configuration |
---|---|---|
hasSubmit | Observable - True/False | Toggles visibility for the big button on the Request Form |
customRequestForm | Observable - Template Object | The template used under the Core Request Intake form |
customSubmit | Function - No Return Value Expected | A custom function that runs when the button is clicked |
jobTemplate | Function - Expected Return: Template Object | This function receives the current Job as it's first input and returns the template used on the "Job Request"/"Batch Job Request" subforms |
Note An example of Template Objects
Requests Widget
- Similarly to the Jobs Widget the Full/Slim Lines for the widget are not includes in Virtual Ticket. They can be copied from old projects (BHC, Iron Mountain, Interstate Batteries, etc.)
- The widget settings can be found under default_my_requests.js
- Client: The client side contains a widget for both VT and Portal, these can be configured to show different things. (For example Portal could have the Drafts tab shown)
- Server: The server side contains an extension of the widget settings. There is an example for pulling information from a job
Job Creation
Requests have function that run on the objectLoaded and objectSaved events.
These functions are determined by the type of the Request.
Note If you are using only one Request Type, then set it as the default.
The Request Type can be set later, but currently there is no way to set it before the first time the entity is loaded.
(This means that if you plan to set the type on client side after the entity is loaded, the default type's objectLoaded function will fire on that first time).
There are two Request Types in core:
Type | Action |
---|---|
Job Request | Creates a single job request that is attached to the Request |
Batch Job Request | Creates multiple jobs that are attached to the Request |
Once the Request has been approved then the Job's Schedule will be started, making the Job appear in the Jobs widget for the related users.
Custom types
These can be specified by adding to the Requests object on the Server Side.
An example of how to set up a "Custom Type"
Note Spaces in request type get replaced with underscores.
So a Request that has a type of "Custom Type" will run the Requests.Custom_Type object loaded/saved functions.
Schedule on Jobs (or associated types)
The schedule on the Job(s) are set using the Project_Type configuration.
This means that the Request Form must capture the Job's Type (Project_Type) before the Request is submitted.
Connecting Requests and Jobs
To connect Jobs and Requests a button can be added to the main Job Request Intake form to open the Request information. The Requests Server-Side provides a function to retrieve the id of the associated Request.
This can be done as well for the Request if you add a button to the Subform that the Request loads. If this button needs to be limited to Internal users then create a separate form that contains the button. Then you can switch between the forms like such: