Improvement of Info forms

From ADempiere
Revision as of 10:42, 4 September 2013 by MJMcKay (Talk) (Status: Update - noticed an error.)

Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

Status

August 25th, 2013: Feature is ready for integration. Both Swing and ZK interfaces complete. A test server with the ADEMPIERE-72 branch is available here. Note: errors in the lookup fields are apparent that don't appear when using eclipse.

Contributors

MJMcKay

Overview

Feature Request: https://adempiere.atlassian.net/browse/ADEMPIERE-72

While the VLookup fields and info windows function, there are many inconsistencies in how they operate. This improvement will attempt to solve some of these inconsistencies and make the swing and ZK behave in an identical fashion.

The inconsistencies include the following:

  • The VLookup fields that cause info windows to open use searches that are different than those performed by the info windows. For example, in GardenWorld, in a Product field on a sales order, entering %Tree will open an info window with only one entry for a Plum Tree. If there is only one entry, the Product field (a VLookup) should have selected that record. Having the info window open with only one gives the user the impression that that is only "Tree" in the product list. In the database there are three entries that match the query performed by the VLookup.
  • If the VLookup field has a record defined and there are more than one identifier column set in the underlying table (in other words, the field displays something like Value_Name), the info window opened when the search button is pressed will not find the record.
  • If the info window is opened from a menu, clicking return will close it unexpectedly.
  • Although the table of search results are read-only, every cell in the table is selectable.
  • Multi Selection is difficult to use for selected more than a few rows. Keyboard navigation is difficult and each row must be selected by mouse click.

Purpose

Purpose of the fix is:

  • to tie the info windows to record ids if these are defined;
  • to clean up the implementation of the windows and make them function more effectively

References

Design Considerations

Changes will include:

  • direct link via the record ID for fields that already have record information saved. The info windows will now be able to display details about that record without any ambiguity in how the record ID is displayed. With this link, the info buttons can remain active on fields where the document is closed but the field is visible.
  • the info windows will be more responsive to and selective of the context in which they were opened and will gather search criteria in an intelligent fashion.
  • an info entry will be added to the popup menu for certain VLookup fields that do not have a search button.
  • A system configuration entry will allow the user to select the default wild card positions as none, beginning, end or both. The default will be end.
  • A system configuration entry will allow the user to set the default behavior to auto query on changes to search criteria. A check box will be added to the info panel to allow the user to override the system config. The default is to not auto query if the system config setting isn't specified.
  • In the info windows, VLookup fields will replace text search fields where this makes sense.
  • zoom capabilities will be added where these don't exist.
  • Where the current info window queries result in multiple lines for each ID, the queries will be simplified to return single results by either, dynamically removing columns from the table where these columns cause the duplication, or by moving the information to a pane below the table. This will mostly affect the Info Product and Info BPartner windows. The Info Product window will have dynamic columns for warehouse quantities which will appear only when a warehouse is selected. Similarly, the price information will only appear if a price list is selected. For the Info BPartner window, the contact and location information will be moved to a pane below the main table.
  • For the Info Product window the following will be added:
    • A check box to select only stocked items
    • A search field for product categories
    • The PAttributeSetInstance button will be changed to a VPattributeSetInstance field so that the ASI criteria can be seen. This will allow products to be searched by attribute.

The changes will be generated in two stages - Swing first and then ZK.

Assumptions

Dependencies

The info window classes use several other classes such as the minigrid, and individual fields. Many of these will require modification to link the fields to the info windows and to allow the fields to be used effectively as criteria in the windows.

Constraints

The changes will not impact any existing functionality

Glossary

Functional Requirements

If the lookup/search field has a record identified in it, regardless how it is displayed, clicking the search button shows display information about that record in a clear and meaningful way.

In ADempiere, the ability to search for and display information is provided in a number of areas. The Tabs provide forms and tables of data. Fields in the tabs can search for information, info windows provide static information and forms can use tables to present information. In general, fields show a specific record and tables are used to show many records, but more importantly, tables can be used to select one or several records.

From a user's perspective, entering data in a search field (see Entering_Data_-_Fields_and_Buttons#Search and Entering_Data_-_Fields_and_Buttons#ID) does not require the user to know the record ID of the associated table but allows the user to enter text to try to find the relevant record. For example, entering "Joe" in a Business Partner field (a VLookup connected to the C_BPartner_ID field) will return Joe Block as the business partner. Where the search terms entered are ambiguous, an info window will open, allowing the user to refine the search and select the desired record. The selected record will be displayed in the search field.

Later, if information is required about the subject of the search field, the user can right-click and zoom to the relevant record, or click on the search button in the field and open the associated info window. The info window will show the selected record. This is useful, for example, on a completed invoice when the user wants to contact a particular Business Partner. Clicking the search button will bring up the Info Business Partner Window with the contact information shown in a subordinate tab. Another example would be for products where it is important to know the quantities of a product in other warehouses.

Another feature of the search fields is multi-selection of records which can be used in Orders to automatically create a number of order lines. When an order is created and the search button clicked in the Product field on the order line, the info window will open and allow multiple products to be selected. When the selection is confirmed, each selected product is added to a new order line on the order. The process allows for rapid filling of orders for a complete category of products.

Apart from the search fields, the tables of data are used in a variety of forms such as the payment allocation form, create from forms, and workflows. In these forms, the selection of multiple lines is similar to the multi-selection of products on orders.

Functional team

  • Volunteers for analyzing:
  • Result of analysis:

User roles & profiles

No impact

Business process definition

Can now use info fields to look up info on closed records. Example: looking at an invoice that has an overdue payment, the business partner field will identify the business partner. Clicking the info button in the field will display info about that business partner including contact info.

User stories

Functional requirements based on business processes

User Interface Mockups

Acceptance criteria

All current processes and documents that use search fields function as expected.

QA and test cases

The swing implementation was tested by hand.

ZK is tested by Sahi and a full Sahi script is available to run this test.

Basic testing involves:

  • Open info window from the menu and use all its features. Search for records, click all the buttons and test all the functionality.
  • Change the display of a table such as product or business partner to use something other than name or value.
  • Open the info window from a field in a window (Sales Order or Sales Order Line). Search for and select a record. Confirm the window and verify that the record is saved in the field.
  • Open the info window from the field again and verify that only one record is displayed and it was the previously selected record. Cancel the window and verify that the field is cleared.
  • Type text that matches a record and verify that the field is filled with the record ID without the record opening. Clear the field.
  • Type text that is not recognized and verify that the field opens and that the text occupies a number of criteria fields and that the AND/OR checkbox (if any) is set to OR.
  • On a new sales order line, select multiple records in the Product Info window and verify that multiple lines are created in the Sales Order - one for each product.

Development infrastructure

Technical Requirements

Technical team

  • Volunteers for analyzing:
  • Result of analysis:

Data Requirements

Non-Functional Requirements

Open Discussion Items

Closed Discussion Items