View source | View content page | Page history | Printable version   

Projects:Editable multi-record grid widget/Specifications


Editable multi-record grid widget - Functional Specifications


A version of the data grid that allows to edit values in the grid. It is referred to in Openbravo Issues by Editable Grid Issue and related to Movable columns in a grid and Save grid layout. The three features should be combined into one. Additional functionality that should be considered is duplication of rows (records). This whole set of features is henceforth referred to as in-grid editing.


The purpose of this project is to add an editable grid to Openbravo ERP plus a set of related additional features in order to facilitate more rapid record entry and manipulation resulting in an increased user satisfaction.



Design Considerations

Best practices

Datatable showing in-grid editing using all most common widgets. Example 1

More of the same. Note that a double click is needed here to start editing and changes are marked on cell level with red corners. Example 2

Datatable in grid-edit-mode. Plenty of products make use of this principle. Note the EDIT button in the left column that takes the user to a form view. Example 3

Image 1: An example of a visual cue after saving.

Visual cue after saving

Image 2 (left): Type-ahead speeds up entry.. (right): Adding values "on the fly".

On the fly addition and type-ahead

Keyboard Operation

The grid is managed as any other page control. The focus is obtained by pressing the tab key coming from a control and by pressing the F6 key coming from a pane.

Once the grid is focused, the movement between cells is done with the cursor keys. When F2 or any other key except for the keys mentioned below is pressed, the selected cell becomes editable. When the enter key is pressed, the entered value is stored but not saved and the focus moves down to the cell below. The F6 key is used to move the focus away from the grid to the next pane.

An entire row or column is selected when the cursor is moved to the top or left border of the grid.

A guideline for other standard keyboard shortcuts is the following list:

Tab, Shift+Tab: Moves keyboard focus to next/previous control

F6, Shift+F6: Give focus to next/previous pane in a paned window

F8: Give focus to splitter bar in paned window. Please note that this sometimes interferes with OS or hardware specific software keyboard shortcuts.

F10: Give focus to browser's menu bar

Shift+F10: Pop up contextual menu for currently-selected objects

Space: Toggle selected state of focused check box, radio button, or toggle button

Return: Activate focused button, menu item etc.

Home, End: Select/move to first item in selected widget PageUp, Ctrl+PageUp, PageDown, Ctrl+PageDown: Scroll selected view by one page up/left/down/right

Mouse Operation

When there is a click inside the grid, the grid gets the focus.

When a header column is pressed, the behaviour is the same as described in Movable columns in a grid.

When any number of the first column is pressed, the corresponding edition window will be opened.

When any other cell is clicked, the cell becomes editable.

When there is an active editable cell and another cell is clicked, the changes of the active editable cell will be saved and the clicked cell will become editable.

Introduction of right-mouse-click functionality should be considered for actions such as copy, paste, delete and column properties.

The Visual Appearance Of Grid Elements

A cell that is being edited and needs a visual cue. Selection of one or multiple editable cells, rows, visible and non-visible columns should also be clearly indicated.

The Saving

The cell saving is made with an asynchronous call after the focus moved out of the row. The entire row is saved.

Currently used widget types

Openbravo ERP 2.40 uses the following widget types for data entry that will need a grid-edit variant:

  1. Text field: a single row field allowing free text entry. At the moment there is no field validation in real time.
  2. Text area: a multiple row text area allowing free text entry, mostly used for descriptions.
  3. Dropdown: list box containing predefined values. The number of values should be limited to avoid long page loads. For in-grid editing it is convenient to have a type-ahead (auto fill) feature.
  4. Selector: invokes a filter popup where queries can be executed. This behavior can be reused for in-grid editing and should be extended with the possibility to enter a value directly into the field.
  5. Date picker: date can be picked using the widget or via keyboard entry. Currently the tolerance for date format input is not very high: only DD-MM-YY(YY) is accepted or DDMMYY(YY). This needs to be extended to at least DD/MM/YY(YY) and DD.MM.YY(YY).
  6. Calculator: numerical value can be generated using a calculator widget. This behavior can be reused for in-grid editing.
  7. Checkbox: can be considered as a binary choice on field level (Y/N) but can also reflect multiple values ("select all colors that you like").
  8. Radio button: can be considered as a binary choice that is mutually exclusive with one or more others. It might be good to use a dropdown in case more than two radiobuttons are used on the form.





In-grid editing: ability to edit values in a table on cell level without having to edit the form itself. This is especially useful for mass entries or in cases where lots of data needs to be duplicated.

Functional Requirements

User roles & profiles

The target users for this project are:

Business process definition

This project is related to all processes that require record editing. Emphasis is placed on processes that require bulk record editing and processes that require creation of multiple similar records.

User stories

User Story 1: Filling out weekly time sheets Fiona is a senior business consultant at a medium sized consulting firm. Once a week she has to enter her time sheet in the ERP system. She always hated it. In the old days, without the in-grid editing feature, this was a tedious process. As a consultant she normally worked on more than one project at the same time, sometimes up to 4 different activities per day. This can result in filling out 20 entries per week. Rough estimate for time spent doing this per window: 90 seconds including load and save. Total time spent is 20 x 90 = 1800 seconds = 30 minutes per week. With the new in-grid editing feature the time she spends on this task is reduced to 15 seconds which results in total time of 300 seconds = 5 minutes per week. This saves her 25 minutes per week!

User Story 2: Bulk changes and duplication of products Marcelo is responsible for product entries. He needs to change the product category from standard to average for 50 products for a certain business partner. On top of that, he needs to add 20 similar products to the product list for this business partner using the same form data except for the name and key. Using the in-grid editing feature, Marcelo now can filter the grid for the business partner and start editing away in the cells of the table, as he would do it in a spreadsheet. He doesn't even need to use the mouse: just navigate to the cell with the arrow keys, hit the F2 key, select the value from the dropdown using the arrow keys again and hit enter to keep the new cell value. With similar ease he adds 20 products to the list by using the copy/duplicate feature. This will take an existing product and duplicates it, creating an additional row in the table. He only has to change the product name and key.

Design Elements

This feature can be split in chunks of functionality. In order of importance:

  1. In-grid-editing
  2. Duplication of records of rows (records)
  3. Manipulate column settings

Functional requirements based on business processes

The following table lists all requirement candidates.

Number Requirement Importance Description Comments User Value Business Value Technical Ease
1.1 Fields are editable in the grid Must have This is the core functionality. High High High
1.2 It is possible to switch the in-grid edit mode off Must have This helps the user avoid making undesired changes. This could be role based but if we choose to do so then the same must be applied to the windows view. Low High Low
1.3 Column width can be modified and will be saved Must have An nuisance since long as current column settings are lost the moment the user moves away from the view. High Medium Low
1.4 Column order can be modified and will be saved Must have An nuisance since long as current column settings are lost the moment the user moves away from the view. High Medium High
1.5 Column visibility can be modified and will be saved Must have An nuisance since long as current column settings are lost the moment the user moves away from the view. High Medium Medium
1.6 Column visibility display logic: show column depending on row values Must have In some cases certain values are too important not too show. High Medium TBD
1.7 Copying of rows (records) in the table. Must have It needs to be decided whether there is a need to include the lines within (or this could be an option). It should even be possible to copy multiple rows. Choice for placement on row above or below could be an option. High Medium Toolbar operated: medium, context menu: medium-high
1.8 Inserting rows Must have Very similar to duplicate but now all values are empty or defaults.CTRL-N could be the keyboard shortcut. Medium Medium Low-medium, especially in combination with copy feature
1.9 All in-grid editing can be done using the keyboard Must have This serves both order entry speed and accessibility compliance reasons. High Medium High (breaks current shortcuts and needs to work with all the insert widgets etc.)
1.10 Saving on record level, not cell level. A record is saved the moment another record is selected. Must have This is a best practice comparable to editing of spreadsheets. From technical point of view it is quite hard to save on cell level. Agreement on that it is best to save on record level. High High High (all saving requires lots of server changes)
1.11 Error handling should be in place Must have Ismael has more details on the requirements for this. High Medium Validation, return to defaults etc.: high
1.12 Copying and pasting of single cell values is possible. CTRL-C and CTRL-V keyboard shortcuts can be used to do so. Should have Serves rapid order entry. High Medium Same column: medium, across columns: high
1.13 Copying and pasting of multiple cell values is possible. CTRL-C and CTRL-V keyboard shortcuts can be used to do so. Nice to have Serves rapid order entry. ICI: This is very difficult to implement Medium Medium Very very high
1.14 There is a clear distinction between editable and non editable fields / columns. Must have This saves the users clicking to no avail. Medium Low Low
1.15 The order in which the rows appear can be changed. Nice to have Currently the rows are numbered and order cannot be controlled. Using something like up and down arrows instead could be handy. Request by user azuledu. This should also change the ID internally. Medium Low Very high
1.16 Conditional defaulting Must have Example: entering a product will automatically calculate and add the line price. Support current definition of default values, validations and callouts. On line record refreshing after changes in values that fires validations and callouts. On line record refreshing after saving with back-end changes in the record (triggers). High High High
1.17 Changing all values in a column. Should have User selects a column and changes all cell values in that column in one go. This is related to multi-record edit. High High Low Medium
1.18 Switch to form view from the grid in the middle of an edit action Must have When user changes her mind and still prefers window view for editing. Medium Medium High to remember focus switching views
1.19 Auto save can be switched On and Off. Must have Similar to the window view. Open item as there is still discussion on the behavior for in-grid edit mode. Medium Medium Medium high
1.20 Changes to the values in the cells of the grid show a visible cue when the table is not saved yet, for example a change of colour. Nice to have This helps the user understand what the impact of saving is. ICI/PJU do not see much value here if we choose to (auto) save on record level. So when user navigates to the next record, the record will be saved. Medium Low Low-medium
1.21 Changes to the values in the cells of the grid show a visible cue when the table is saved, for example an "Updated" callout. Nice to have The added value of this feature needs to be investigated. Perhaps in a multi user environment it is handy to verify what other users have modified. ICI/PJU do not see much value here. Medium Low Low-medium

Use Cases

Use case: Editing cell(s) in grid

Precondition: grid view is active


  1. User toggles in-grid-editing on
  2. User selects an editable cell
  3. User changes value
  4. User navigates to other cells in the same row and changes more values
  5. User navigates to another row
  6. System saves the new values

Alternative paths:

  1. User navigates to any other window: user is prompted to either save or lose changes
Use case: Duplicating rows

Precondition: grid view is active


  1. User selects a row (record)
  2. User starts the duplication
  3. System copies mandatory fields
  4. System generates a unique identifier based on sequence
  5. The row is duplicated and added to the grid

Image 1: Example of child-parent relations


Use case: Manipulating column settings

Precondition: grid view is active


  1. User changes column order
  2. User changes column widths
  3. User choose which columns to display
  4. System saves the new column settigs
Use case: Multi record edit

Precondition: grid view is active


  1. User selects multiple rows
  2. System shows a set of values that can be edited for all the selected records
  3. User changes the values
  4. User saves the new values

User Interface Mockups

Mock 1: Buttons grouped by “reach” and addition of Copy and Process buttons

Buttons grouped by reach

Technical Requirements

{{{Technical Requirements}}}

Data Requirements

{{{Data Requirements}}}

Non-Functional Requirements

{{{Non-Functional Requirements}}}

Open Discussion Items

  1. Scope: Common agreement is that we should aim to build functionality that is reusable on the longer term when we plan to redesign the master-detail display and interaction. Therefore the scope for this feature is still under discussion.

Closed Discussion Items

{{{Closed Discussion Items}}}




Retrieved from ""

This page has been accessed 12,924 times. This page was last modified on 8 June 2012, at 05:27. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.