This spec is out of date! New spec page in google docs
KRAD should support the display of and user interaction with application forms that have arithmetic calculations/relationships among form fields that must be met. For example, the user should be able to see the results of entries they make into form fields that affect the total (or other value) elsewhere on the form. In this way, users are given helpful feedback about numeric values they enter, "live" and inline in the form, while they are filling it out, without having to submit it to see the results of calculations.
In addition, KRAD should support the optional display of table-based data, inline in the table itself, of additional properties associated with each row. See the Mocks and Diagrams section below.
See the Requirements section below.
See the Mocks and Diagrams section that follows.
Below is an example showing automatic updating of the total amount, based on entries in a collection. In this example, the total shown at the bottom of the collection is read-only, based on the amounts in the collection rows. In KNS, updating the totals typically requires a refresh of the page. A requirement in KRAD, is to be able to make this into a conditional refresh of the totals field or, alternatively of the collection, with the objective being to not require a refresh of the entire page:
A variation on this example above could be a matching of a target total with the amounts entered per row, displaying a client-side validation error if/when the amounts entered exceed the total amount allowed.
Below is an example from KFS, in which the user can "Drill Down" to view the balances by Object Code:
Note: KFS adds up the balances displayed above it by various attributes that are not shown in the UI, for example, by income or expense; budget, actual or encumbrance; transfer activity, and so on. Therefore, you might not be able to intuit the calculations from the #s shown in the user interface in this example above.
In the following example, the details are additional properties of the row, that are displayed (laid out) out in a way that is conceptually similar to a sub-grouping (though these details are not actually a subgroup/subcollection, they are additional properties of the row displayed in this way). These could be displayed conditionally (in a way similar to drilling down - see example 2.b., or by default as shown in the example below:
Details such as those shown above can be conditionally shown, enabling a collapsed and more expanded view by row similar to show/hide). In this example below, the rows are grouped by attributes and allow drill down (& show/hide all could be supported for the entire collection) for the detail records.
Alternative ways to show or hide details, under user's control, are shown below:
If applicable, list expectations for performance (optimal and worst cases would be fine, give time in seconds):
(Item 2 is listed in the secondary requirements section as it is unknown if this item would require a larger work effort than can fit within the 2.2 development cycle timeframe. For more on this, see KRAFDBCK-8143)
List any functional or technical work that must be completed before work on this item can begin:
List any issues that need to be resolved before work on this item can begin:
List steps needed to test the basic functionality of this update, enhancement, bug fix
Functional Analysis Complete? No (completed by SME)
Needs Review by KAI? No (completed by SME)
Technical Analysis Complete? No (completed by DM)
Needs Review by KTI? No (completed by DM)
Estimate: 30 hours (completed by DM)
Technical Design: Link Here (completed by DM)
Final Documentation: Link Here (completed by DM)
Added to QA: No (completed by SME)