Projects/Centralized control changes/Functional Specifications

Centralized control changes - Functional Specifications

Overview

Purpose

The purpose of this project is to centralize in a single component all the interaction between the user interface and the backend, to be able to capture some special events and perform additional tasks before such as autosave.

Current implementation

Problems

• One of the main benefits of this project is to be able to save a record before perform an action. e.g. posting an invoice, go from header to lines, etc. If you made some of this actions without saving the current record you'll get a message like this one:

Solution

• The proposed solution should solve this main issue. Instead of telling the user that will loose his/her changes, is better to pop-up a message like: There are changes in the current record. Do you want to save the changes?

• The Application administrator should be able to define as a Preference per Window and/or User if a prompt confirmation is needed. The preference should be defined as ShowConfirmation, with value Y for yes and N for no.
• A global behavior should be defined as a Preference at System level to define if autosave is enabled. The preference should be defined as Autosave with a valut Y for yes and N for no. Note that this global behavior can be override at Client level, defining the same Preference for a Client.
• A global behavior should be defined as a Preference at System level. The preference should be defined as ShowConfirmationDefault, with value Y for yes and N for no.
• A new confirmation message is displayed to the user when the the autosave behavior is off, or an error trying to save occurs.

Scope

• This project affects all the automatically generated windows.
• Iteration 1:
  • Identify which is the component in the current architecture that should receive all the requests from the UI
  • Prototype a solution based on changes in this component(s)
• Iteration 2:
  • Modify WAD to generate code based on the prototype's solution

Glossary

WAD: Wizard Application Dictionary

Functional Requirements

User roles & profiles

• All user roles will be affected by this functionality, since it will change the way of interacting with the application.

Business process definition

User stories

• Story 1:
  • Maria is a procurement clerk, she logs in into the application
  • Go to the Procurement module
  • Creates a new Purchase order
  • Without saving the record (clicking the save button):
  • Clicks on the Lines tab
  • A pop-up message appears: There are changes in the current record. Do you want to save the changes?
  • Clicks OK
  • The header record was saved before going to the lines tab

• Story 2: 2.50 Behavior - Auto-save on
  • User enters a partial transactions and navigates away
  • System autosaves. If saves successful, navigation continues.
  • If save fails, system displays pop-up window with message "The current record could not be saved automatically and you will lose your changes if you continue. Press 'Cancel' to go back or 'OK' to discard them and continue with your action". Buttons: Cancel and OK.
  • If users press Cancel the pop-up closes and they are back to where they were before attempting to navigate away.
  • If users press OK, they continue with the navigation and loose the data.

• Story 3: 2.50 Behavior - Auto-save off
  • User enters a partial transactions and navigates away
  • System displays pop-up window with message "The current record could not be saved automatically and you will lose your changes if you continue. Press 'Cancel' to go back or 'OK' to discard them and continue with your action". Buttons: Cancel and OK.
  • If users press Cancel the pop-up closes and they are back to where they were before attempting to navigate away.
  • If users press OK, they continue with the navigation and loose the data.

Functional requirements based on business processes

To achieve the desired functionality we need to:

• Define the component that will receive the UI requests
• Prototype a solution for one generated window

Technical Requirements

• The Front Controller pattern applies to Openbravo ERP.
  • Logic that is best handled in one central location.
  • A centralized point of contact for handling a request may be useful, for example, to control and log a user's progress through the site.

Non-Functional Requirements

Known Issues

Open Discussion Items

Closed Discussion Items