Publish Dialog Description:
The publish dialog has three modes: PI, Department and Common. PI and Department each have two submodes: Overwrite Existing Forecast and Create New Forecast. Publishing to Common ALWAYS is an overwrite of the existing single forecast. Publishing is a one time copy of the forecast information on a single cost object. The source cost object and the destination cost object MUST be the same to copy a forecast. What differs is whether the forecast ALREADY EXISTS on the destination cost object, in which case the user will be overwriting it, or if it does not exist, the user is ADDING it to the existing forecasts on that cost object.
Code Flow Chart for Publish Dialog:
- Get forecast name from Forecast Model, display it in Source Forecast/ Forecast Name field.
- Get forecast cost object name from raft.data.CostObject.COTITLE, display it in Source Forecast/ Forecast Cost Object field.
- Get forecast workset name from raft.data.Workset.title, display it in Source Forecast/ Forecast Workset field.
- Display three radio buttons: PI, Department, Common. Put change event listener on the radio buttons.
PI RadioButton Clicked
- Show Overwrite Existing and Create New buttons. Add click listeners to both.
- Show Overwrite Destination Forecast in dialog. Add click listener.
- Display in Destination Forecast the Name of the PI, which is raft.data.CostObject.SUPERVISOR.
- Get forecast cost object name from raft.data.CostObject.COTITLE, display it in Destination Forecast/ Forecast Cost Object field.
Get the list of forecasts to display by searching raft.data.CostObject.Forecasts[] for the worksetCategory == PI. All PI Forecasts should be listed in the Destination Forecast List.
- On click, call publish/share forecast with the selected forecast key as the destination scenarioKey, and the rest of the data from above as needed. Close dialog.
Department RadioButton Clicked
- Show Overwrite Existing and Create New buttons. Add click listeners to both.
- Show Overwrite Destination Forecast in dialog. Add click listener.
- Display in Destination Forecast the Name of the PI, which is raft.data.CostObject.SUPERVISOR.
- Get forecast cost object name from raft.data.CostObject.COTITLE, display it in Destination Forecast/ Forecast Cost Object field.
Get the list of forecasts to display by searching raft.data.CostObject.Forecasts[] for the worksetCategory == PI. All PI Forecasts should be listed in the Destination Forecast List.
- On click, call publish/share forecast with the selected forecast key as the destination scenarioKey, and the rest of the data from above as needed. Close dialog.
Page Mockup:
Page Layout: This page consists of a main grid/form for forecasting, a forecasting totals block that follows the user as they scroll down, and a "To Be Hired" block that contains To Be Hired templates (grad student, research assistant, research scientist, etc.). The forecasting form/grid is further broken down into GL sections, one for each of the high level CEMIT or Approved GLS. Each GL block contains a subtotals block at the bottom.
Functional Summary: On first entry, the left nav is hidden, the name and description are blank, all GL blocks are open, and the people are shown in their data range view. If the user wants, they can close each block of existing commitments. Above each existing commitment in each GL block is an empty row so users can immediately begin forecasting. When a user gets to the last input field in the row, a new blank row is automatically added. In addition and not shown in the image is a "Add new row" button on each block. If a user wants to add a To Be Hired, they click on them and a new row is added that contains the defaults from the To Be Hired they clicked on, which can then be edited.
Any time a user creates a new forecast, they are taken here and have to supply a new name and description. If they are editing an existing forecast, they also come here but the name and description are open for editing. If a user edits the title, this does NOT create a new forecast, it just edits the existing name (we maintain a unique forecast id under the hood). A forecast is saved in a special table in the backend, one per user. This table allows users to edit one forecast as much as they want without committing it. When they click Save, the system will validate the forecast and save it if it passes validation.
Description of the Page: This page gives a user the ability to edit a particular cost object forecast. Users can add a line (person, TBH, expense) then edit it. Users can edit existing speculations that came from SAP as People Commitments from ESDS and as Blanket POs or Manual Commitments for expenses.
A forecast can be published (copied) to the following three places: the PI Workset/Scenario, the Department Workset/Scenario, or the MIT ALL Scenario.
Specify user all actions available on the page. Specify destination of navigation buttons or hyperlinks. Insert one or more annotated screen mock ups to show the page in representative states.
Table 1: Common User Interface Elements for the Forecasting Detail Page
This table includes all elements that appear on this page. Flag elements that have appeared on other pages.
Element |
Control |
Functional Description |
Technical Rules |
|---|---|---|---|
Name field |
text input |
User stores and edits Forecast name |
Defaults to "MIT-All Forecast", key is COMMON (which is MITALL) |
Show's actuals and commitments |
checkbox |
User clicks on it to show and hide existing commitments |
Defaults to checked, should be placed closer to grid it controls |
Show/Hide Accordion |
button |
Shows and hides all commitments in GL block |
Overrideable by the Show Actuals and Commitments checkbox (if user hides people block, clicks hide all, then clicks show all, people block is visible) |
Person name field |
text input |
User can search for person (autocomplete) including TBHs |
After third keydown, set timeout for 300 miliseconds, if no further keydown, execute search call (wait until the user pauses). Make timeout length a setting, let us play with it, hide setting for January release and default to best guess. Show default if users complain. |
Appointment field |
dropdown list (select) |
Until you choose a person, the only thing in the Appointment field is "choose a person". If you choose a person, the appointment field gets filled with the one or more appointments they have. If they choose a TBH, the appointment is filled in by the choice. |
Until appointment is chosen, other people fields to the right are hidden. Once appointment call to backend is made and speculation id is returned, other fields are then shown with default values from call. |
Start Date |
text input with calendar widget |
Normal calendar widget behavior (opens auto on focus of field, can be overridden by user) |
Required field. Normal Calendar widget behavior, hidden until appointment is chosen |
End Date |
text input with calendar widget |
Normal calendar widget behavior |
Required field. Normal Calendar widget behavior, hidden until appointment is chosen |
Allocation |
text input |
User enters number |
Required field. Floating number rounded to nearest two decimals (percentage), hidden until appointment is chosen |
Hours per week |
text input |
User enters number |
Required field. Floating number rounded to nearest two decimals, hidden until appointment is chosen |
Tuition |
text input |
User enters number for tuition |
Required field. Floating number locked to two decimals (money), hidden until appointment is chosen |
Comment |
text area |
User enters description. User can grow text box if wanted |
Not required. Shrink text area to make inline row, let them expand it they want. |
Add Row |
button |
Adds new row of the same type below existing lines |
|
Save button |
button |
|
Always appears. |
Save As Button |
button |
|
Only active (change state from gray to active) if forecast has been saved at least once, ie not when new forecast is being created. |
Revert Button |
button |
|
Only active (change state from gray to active) after forecast has been saved at least once. |
Publish Button |
button |
Opens dialog that asks user where do they want to publish to: PI, Department or MITALL |
|
Table X: Validation Rules for [name of page] Page
Validation |
Message |
|---|---|
cell A1 |
Lorem ipsum dolor sit amet |
cell B1 |
Consetetur sadipscing elitr |
cell C1 |
Sed diam nonumy eirmod tempor inviduant ut labore |
cell D1 |
Labore et dolore magna aliquyam erat, sed diam voluptua |
Repeat for each screen of the application.
DISP handling:
Breakdown of people line types |
|
|
|
|
|
DISP |
Description |
changePerson |
changeAppt |
editAppt |
changeSpeculation |
ACT |
Historical info from SAP |
N |
N |
N |
N |
COMM |
Commited info from ESDS |
N |
N |
N |
Y |
FORC |
Forecasted person from RAFT |
Y |
Y |
N |
Y |
TBH |
TBH – synthetic person defined in RAFT |
N |
N |
Y |
Y |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Notes |
|
|
|
|
|
An edited COMM is currently returned as a FORC. This will be corrected |
|
|
|
||
|
|
|
|
|
|
ChangePerson = change the name/personnel key |
|
|
|
|
|
ChangeAppt = select a different appt from a list of appts. |
|
|
|
||
EditAppt = Edit the appt information (salary, pay_rate) |
|
|
|
||
ChangeSpeculation = Edit the allocation % |
|
|
|
|