FS 311636 UDF Modifications - Revision history

Anw: Clarified Config Types in new Admin screen

2013-10-08T14:48:41Z

Clarified Config Types in new Admin screen

← Older revision		Revision as of 16:48, 8 October 2013
Line 219:		Line 219:
	*** Product Group (value "P")		*** Product Group (value "P")
	** Key Value - the key item from the key type selected. This will be displayed as a drop-down list and will be populated with values when a Key Value has been chosen.		** Key Value - the key item from the key type selected. This will be displayed as a drop-down list and will be populated with values when a Key Value has been chosen.
			** Config Type - one of:
			*** "INFO" - labelled as "Service - Info"
			*** "PREWORK" - labelled as "Service - Pre-work Checks"
			*** "POSTWORK" - labelled as "Service - Post-work Checks"
			*** "DIAGNOSIS" - labelled as "Service - Diagnosis/Completion"
	{{Note}} Changing the Key Type should blank the Key Value and require the value to be entered again.		{{Note}} Changing the Key Type should blank the Key Value and require the value to be entered again.

Anw: Clarified EPL_KEY_TYPE values - now matches subsequent specifications.

2013-10-07T10:10:12Z

Clarified EPL_KEY_TYPE values - now matches subsequent specifications.

← Older revision		Revision as of 12:10, 7 October 2013
Line 453:		Line 453:
	* EPL_PRODUCT_GROUP - "PG01"		* EPL_PRODUCT_GROUP - "PG01"
	The procedure should fetch all configurations for key elements as follows:		The procedure should fetch all configurations for key elements as follows:
	* EPL_CONFIG_TYPE = "INFO" AND EPL_KEY_TYPE = "~~SITE~~" and EPL_KEY_VALUE = "TEST"		* EPL_CONFIG_TYPE = "INFO" AND EPL_KEY_TYPE = "S" and EPL_KEY_VALUE = "TEST"
	* EPL_CONFIG_TYPE = "INFO" AND EPL_KEY_TYPE = "~~JOB_GROUP~~" and EPL_KEY_VALUE = "JG01"		* EPL_CONFIG_TYPE = "INFO" AND EPL_KEY_TYPE = "J" and EPL_KEY_VALUE = "JG01"
	* EPL_CONFIG_TYPE = "INFO" AND EPL_KEY_TYPE = "~~PROD_GROUP~~" and EPL_KEY_VALUE = "PG01"		* EPL_CONFIG_TYPE = "INFO" AND EPL_KEY_TYPE = "P" and EPL_KEY_VALUE = "PG01"
	The lowest hierarchical record found will be returned, in this case, the Product Group record, as a DAL object.		The lowest hierarchical record found will be returned, in this case, the Product Group record, as a DAL object.

Anw: /* Admin */

2013-10-07T10:07:56Z

Admin

← Older revision		Revision as of 12:07, 7 October 2013
Line 215:		Line 215:
	** Description - A required description of the configuration being created.		** Description - A required description of the configuration being created.
	** Key Type - the level at which this is being created. Currently one of:		** Key Type - the level at which this is being created. Currently one of:
	*** Site		*** Site (value "S")
	*** Job Group		*** Job Group (value "J")
	*** Product Group		*** Product Group (value "P")
	** Key Value - the key item from the key type selected. This will be displayed as a drop-down list and will be populated with values when a Key Value has been chosen.		** Key Value - the key item from the key type selected. This will be displayed as a drop-down list and will be populated with values when a Key Value has been chosen.
	{{Note}} Changing the Key Type should blank the Key Value and require the value to be entered again.		{{Note}} Changing the Key Type should blank the Key Value and require the value to be entered again.

Anw: Added pre-setting of UDF values, if already entered once.

2013-10-07T10:06:25Z

Added pre-setting of UDF values, if already entered once.

← Older revision		Revision as of 12:06, 7 October 2013
Line 443:		Line 443:
	The highest available configuration in the hierarchy will be returned as a PDA_UDF_GROUP object. If one is not found, null will be returned.		The highest available configuration in the hierarchy will be returned as a PDA_UDF_GROUP object. If one is not found, null will be returned.

	The suggested name for this function is ~~GetUDFConfig~~.		The suggested name for this function is getUDFConfig.

	Example:		Example:
Line 470:		Line 470:
	** Option entry		** Option entry
	** Check Field Group entry		** Check Field Group entry
			* Pre-populate the value, if already entered
	* Produce Results in a pre-defined XML format		* Produce Results in a pre-defined XML format
	{{Note}} An object has already been written to do this, utilising Titanium Tables, and is used in Vehicle Checks. This object should be modified to allow the additional functionality specified above, whilst maintaining compatibility with the Vehicle Checks functionality.		{{Note}} An object has already been written to do this, utilising Titanium Tables, and is used in Vehicle Checks. This object should be modified to allow the additional functionality specified above, whilst maintaining compatibility with the Vehicle Checks functionality.
Line 496:		Line 497:

	These new attribute items apply to the object that calls the UDF form, whereas the buttons apply to the object itself.		These new attribute items apply to the object that calls the UDF form, whereas the buttons apply to the object itself.

			The VALUE tag will now be checked - if this is present on the field, the value of the entry object will be preset to the value in the VALUE tag. For DDL items, this vaue will take precedence over any default item.

	{{Note}} See existing test code in Pre- and Post-work checks in Services for information as to how this object works in its original form, and guidance as to how this will change applying the changes in this specification.		{{Note}} See existing test code in Pre- and Post-work checks in Services for information as to how this object works in its original form, and guidance as to how this will change applying the changes in this specification.
Line 532:		Line 535:
	* PDA_UDF_DIAGNOSIS		* PDA_UDF_DIAGNOSIS

	In the Diagnosis section, A fixed-size, vertical-layout UDF form will be added to the view under any existing fields. This will be created with the ~~passed~~-~~configuration~~, if the ~~configuration~~ is not null.		In the Diagnosis section, A fixed-size, vertical-layout UDF form will be added to the view under any existing fields. This will be created with the value in the new field EPL_UDF_DIAGNOSIS from the in-progress EPOD_SERVICE record, if this contains a value, or using EPL_FIELDS of the PDA_UDF_DIAGNOSIS object, if this object is not null.

	In the Info section, the section will be modified to be contained within a scrolling vertical-layout view. {{Note}} This is similar to how the existing Diagnosis tab is structured now, so this code should be used as source. A fixed-size, vertical-layout UDF form will be added to the view under any existing fields, if the configuration is not null.		In the Info section, the section will be modified to be contained within a scrolling vertical-layout view. {{Note}} This is similar to how the existing Diagnosis tab is structured now, so this code should be used as source. A fixed-size, vertical-layout UDF form will be added to the view under any existing fields, if the configuration is not null. This will be created with the value in the new field EPL_UDF_INFO from the in-progress EPOD_SERVICE record, if this contains a value, or using EPL_FIELDS of the PDA_UDF_INFO object, if this object is not null.

	{{Note}} If the Service Group is being entered on the Info screen, all UDF configuration items should be refreshed, as this could potentially affect the UDF fields configuration. Once refreshed, the old and new configurations should be compared and, if different, the UDF objects affected should be rebuilt. As this may take some time, an Activity Indicator should be displayed.		{{Note}} If the Service Group is being entered on the Info screen, all UDF configuration items should be refreshed, as this could potentially affect the UDF fields configuration. Once refreshed, the old and new configurations should be compared and, if different, the UDF objects affected should be rebuilt. As this may take some time, an Activity Indicator should be displayed.

	The Info section should also check the Pre-work UDF configuration. If this is present, the Pre-work button should be created with the label as defined in the configuration. The Pre-work pop-up should be triggered from this, passing in the ~~configuration setting~~.		The Info section should also check the Pre-work UDF configuration. If this is present, the Pre-work button should be created with the label as defined in the configuration. The Pre-work pop-up should be triggered from this, passing the value in the new field EPL_UDF_PREWORK from the in-progress EPOD_SERVICE record, if this contains a value, or using EPL_FIELDS of the PDA_UDF_PREWORK object, if this object is not null.

	The Pre-work pop-up screen will be modified to replace the current fields and buttons with a scrolling vertical-layout view, if the flag PDAJOBGROUP.EPL_SERVICE_PREWORK is not "Y" or "N". The view should be 70% height, allowing for up to 2 buttons and a title on the screen. The title should be set to the NAME parameter of the configuration settings. The buttons should be created from the buttons passed in in the configuration settings. The button type will define what actions are to be taken:		The Pre-work pop-up screen will be modified to replace the current fields and buttons with a scrolling vertical-layout view, if the flag PDAJOBGROUP.EPL_SERVICE_PREWORK is not "Y" or "N". The view should be 70% height, allowing for up to 2 buttons and a title on the screen. The title should be set to the NAME parameter of the configuration settings. The buttons should be created from the buttons passed in in the configuration settings. The button type will define what actions are to be taken:
Line 548:		Line 551:
	When exiting the Pre-work pop-up screen, the value of the Confirm parameter and the returned XML string should be stored, for validating later.		When exiting the Pre-work pop-up screen, the value of the Confirm parameter and the returned XML string should be stored, for validating later.

	The Diagnosis section should also check the Post-work UDF configuration. If this is present, the Post-work button should be created with the label as defined in the configuration. The Post-work pop-up should be triggered from this, passing in the ~~configuration setting~~.		The Diagnosis section should also check the Post-work UDF configuration. If this is present, the Post-work button should be created with the label as defined in the configuration. The Post-work pop-up should be triggered from this, passing the value in the new field EPL_UDF_POSTWORK from the in-progress EPOD_SERVICE record, if this contains a value, or using EPL_FIELDS of the PDA_UDF_POSTWORK object, if this object is not null.

	The Post-work pop-up screen will be modified to replace the current fields and buttons with a scrolling vertical-layout view, if the flag PDAJOBGROUP.EPL_SERVICE_POSTWORK is not "Y" or "N". The view should be 70% height, allowing for up to 2 buttons and a title on the screen. The title should be set to the NAME parameter of the configuration settings. The buttons should be created from the buttons passed in in the configuration settings. The button type will define what actions are to be taken:		The Post-work pop-up screen will be modified to replace the current fields and buttons with a scrolling vertical-layout view, if the flag PDAJOBGROUP.EPL_SERVICE_POSTWORK is not "Y" or "N". The view should be 70% height, allowing for up to 2 buttons and a title on the screen. The title should be set to the NAME parameter of the configuration settings. The buttons should be created from the buttons passed in in the configuration settings. The button type will define what actions are to be taken:
Line 558:		Line 561:
	When exiting the Post-work pop-up screen, the value of the Confirm parameter and the returned XML string should be stored, for validating later.		When exiting the Post-work pop-up screen, the value of the Confirm parameter and the returned XML string should be stored, for validating later.

	The validation against the OK button should check whether any of the above configurations are present. If so, the following validation checks should be added to the validateService function:		The validation against the '''OK''' button should check whether any of the above configurations are present. If so, the following validation checks should be added to the validateService function:
	* If PDA_UDF_PREWORK is not null and the Confirm property of the Pre-work pop-up is I (Ignore) or unset, a message should be displayed requiring the user to enter the Pre-work checks, referred to by the Name element of the Pre-work configuration. The device should return the user to the services screen on clearing this message.		* If PDA_UDF_PREWORK is not null and the Confirm property of the Pre-work pop-up is I (Ignore) or unset, a message should be displayed requiring the user to enter the Pre-work checks, referred to by the Name element of the Pre-work configuration. The device should return the user to the services screen on clearing this message.
	* If PDA_UDF_POSTWORK is not null and the Confirm property of the Pre-work pop-up is I (Ignore) or unset, a message should be displayed requiring the user to enter the Post-work checks, referred to by the Name element of the Post-work configuration. The device should return the user to the services screen on clearing this message.		* If PDA_UDF_POSTWORK is not null and the Confirm property of the Pre-work pop-up is I (Ignore) or unset, a message should be displayed requiring the user to enter the Post-work checks, referred to by the Name element of the Post-work configuration. The device should return the user to the services screen on clearing this message.
Line 569:		Line 572:
	* If PDA_UDF_DIAGNOSIS is not null, save the resulting XML from the Diagnosis UDF object into the new Service field EPL_UDF_DIAGNOSIS.		* If PDA_UDF_DIAGNOSIS is not null, save the resulting XML from the Diagnosis UDF object into the new Service field EPL_UDF_DIAGNOSIS.

	<!-- MEDIA LANDSCAPE YES -->		<!-- MEDIA LANDSCAPE YES -->

	= Appendix A: TEST PLAN =		= Appendix A: TEST PLAN =
	{{TestPlan_Header		{{TestPlan_Header

Anw: Added definition of Service Export XML from Server.

2013-10-07T07:44:30Z

Added definition of Service Export XML from Server.

@@ Line 128: / Line 128: @@
 *    Export the new fields in XML requests
 *    Read the new fields
 {{Note}} It is not necessary to add this flag as a searchable item. However, if allowing this keeps the packages and DAL objects standard in design, then this can also be done, within the DAL and the packages.
 == Server ==

Anw: v0.4 - Updated with changes to Linking Fields

2013-10-04T10:07:19Z

v0.4 - Updated with changes to Linking Fields

Show changes

Anw: Corrected Pre- and Post-work errors.

2013-09-11T12:12:18Z

Corrected Pre- and Post-work errors.

Anw: Added: EPOD_SERVICE XML export structure; Service Group mods; DDL type modifications

2013-09-06T08:48:18Z

Added: EPOD_SERVICE XML export structure; Service Group mods; DDL type modifications

@@ Line 145: / Line 145: @@
   </EPOD_CONFIGS>
 This section will be added after all existing sections.
 == Admin ==
@@ Line 224: / Line 226: @@
 == Android Client ==
 The database will be modified to add the new table EPOD_UDF_CONFIG.
 The Webservices.LOGON_RESPONSE processing function will be modified to add all new EPOD_UDF_CONFIG messages.
@@ Line 383: / Line 454: @@
 {{Note}} See existing test code in Pre- and Post-work checks in Services for information as to how this object works in its original form, and guidance as to how this will change applying the changes in this specification.
 {{Note}} If a new UDF object is written, it should be written without the use of the Titanium tables, as these are notoriously memory-hungry - instead, use multiple Views in a vertical layout, as can be seen in Signature Container list.
@@ Line 419: / Line 492: @@
 In the Info section, the section will be modified to be contained within a scrolling vertical-layout view. {{Note}} This is similar to how the existing Diagnosis tab is structured now, so this code should be used as source. A fixed-size, vertical-layout UDF form will be added to the view under any existing fields, if the configuration is not null.
-{{Note}} If the Service Group is being entered on the Info screen, PDA_UDF_POSTWORK configuration item should be refreshed, as this will affect the UDF fields configuration.
+{{Note}} If the Service Group is being entered on the Info screen, all UDF configuration items should be refreshed, as this could potentially affect the UDF fields configuration. Once refreshed, the old and new configurations should be compared and, if different, the UDF objects affected should be rebuilt. As this may take some time, an Activity Indicator should be displayed.
 The Info section should also check the Post-work UDF configuration. If this is present, the Post-work button should be created with the label as defined in the configuration. The Post-work pop-up should be triggered from this, passing in the configuration setting.

Anw at 12:51, 5 September 2013

2013-09-05T12:51:55Z

← Older revision		Revision as of 14:51, 5 September 2013
Line 774:		Line 774:
	\|ST=2.0		\|ST=2.0
	\|IMP=0		\|IMP=0
			\|FOC=Y
	\|Client={{#var:Client}}		\|Client={{#var:Client}}
	\|Year={{#var:Year}}		\|Year={{#var:Year}}

Anw: v0.3 - Final draft - Added test plan.

2013-09-05T11:00:09Z

v0.3 - Final draft - Added test plan.

Show changes

← Older revision		Revision as of 14:12, 11 September 2013
Line 494:		Line 494:
	{{Note}} If the Service Group is being entered on the Info screen, all UDF configuration items should be refreshed, as this could potentially affect the UDF fields configuration. Once refreshed, the old and new configurations should be compared and, if different, the UDF objects affected should be rebuilt. As this may take some time, an Activity Indicator should be displayed.		{{Note}} If the Service Group is being entered on the Info screen, all UDF configuration items should be refreshed, as this could potentially affect the UDF fields configuration. Once refreshed, the old and new configurations should be compared and, if different, the UDF objects affected should be rebuilt. As this may take some time, an Activity Indicator should be displayed.

	The Info section should also check the ~~Post~~-work UDF configuration. If this is present, the ~~Post~~-work button should be created with the label as defined in the configuration. The ~~Post~~-work pop-up should be triggered from this, passing in the configuration setting.		The Info section should also check the Pre-work UDF configuration. If this is present, the Pre-work button should be created with the label as defined in the configuration. The Pre-work pop-up should be triggered from this, passing in the configuration setting.

	The ~~Post~~-work pop-up screen will be modified to replace the current fields and buttons with a scrolling vertical-layout view, if the flag PDAJOBGROUP.~~EPL_SERVICE_POSTWORK~~ is not "Y" or "N". The view should be 70% height, allowing for up to 2 buttons and a title on the screen. The title should be set to the NAME parameter of the configuration settings. The buttons should be created from the buttons passed in in the configuration settings. The button type will define what actions are to be taken:		The Pre-work pop-up screen will be modified to replace the current fields and buttons with a scrolling vertical-layout view, if the flag PDAJOBGROUP.EPL_SERVICE_PREWORK is not "Y" or "N". The view should be 70% height, allowing for up to 2 buttons and a title on the screen. The title should be set to the NAME parameter of the configuration settings. The buttons should be created from the buttons passed in in the configuration settings. The button type will define what actions are to be taken:
	* If this is a Confirm button, the changes will be validated and, if OK, will be saved, the confirm attribute will be set to the type and the pop-up will exit.		* If this is a '''Confirm''' button, the changes will be validated and, if OK, will be saved, the confirm attribute will be set to the type and the pop-up will exit.
	* If this is an Ignore button, the changes will be saved, the confirm attribute will be set to the type and the pop-up will exit.		* If this is an '''Ignore''' button, the changes will be saved, the confirm attribute will be set to the type and the pop-up will exit.
	* If this is a Cancel button, the changes will not be saved, the confirm attribute will be set to the type and the pop-up will exit.		* If this is a '''Cancel''' button, the changes will not be saved, the confirm attribute will be set to the type and the pop-up will exit.
	In all cases, if the Confirm attribute is present on the button, a Yes/No confirmation message will be displayed before the actions, displaying the message configured on the device. If the user chooses Yes, the actions above will be taken. If the user chooses No, they will be returned to the pop-up screen.		In all cases, if the Confirm attribute is present on the button, a Yes/No confirmation message will be displayed before the actions, displaying the message configured on the device. If the user chooses Yes, the actions above will be taken. If the user chooses No, they will be returned to the pop-up screen.

	When exiting the Pre-work pop-up screen, the value of the Confirm parameter and the returned XML string should be stored, for validating later.		When exiting the Pre-work pop-up screen, the value of the Confirm parameter and the returned XML string should be stored, for validating later.

	The Diagnosis section should also check the ~~Pre~~-work UDF configuration. If this is present, the ~~Pre~~-work button should be created with the label as defined in the configuration. The ~~Pre~~-work pop-up should be triggered from this, passing in the configuration setting.		The Diagnosis section should also check the Post-work UDF configuration. If this is present, the Post-work button should be created with the label as defined in the configuration. The Post-work pop-up should be triggered from this, passing in the configuration setting.

	The ~~Pre~~-work pop-up screen will be modified to replace the current fields and buttons with a scrolling vertical-layout view, if the flag PDAJOBGROUP.~~EPL_SERVICE_PREWORK~~ is not "Y" or "N". The view should be 70% height, allowing for up to 2 buttons and a title on the screen. The title should be set to the NAME parameter of the configuration settings. The buttons should be created from the buttons passed in in the configuration settings. The button type will define what actions are to be taken:		The Post-work pop-up screen will be modified to replace the current fields and buttons with a scrolling vertical-layout view, if the flag PDAJOBGROUP.EPL_SERVICE_POSTWORK is not "Y" or "N". The view should be 70% height, allowing for up to 2 buttons and a title on the screen. The title should be set to the NAME parameter of the configuration settings. The buttons should be created from the buttons passed in in the configuration settings. The button type will define what actions are to be taken:
	* If this is a Confirm button, the changes will be validated and, if OK, will be saved, the confirm attribute will be set to the type and the pop-up will exit.		* If this is a '''Confirm''' button, the changes will be validated and, if OK, will be saved, the confirm attribute will be set to the type and the pop-up will exit.
	* If this is an Ignore button, the changes will be saved, the confirm attribute will be set to the type and the pop-up will exit.		* If this is an '''Ignore''' button, the changes will be saved, the confirm attribute will be set to the type and the pop-up will exit.
	* If this is a Cancel button, the changes will not be saved, the confirm attribute will be set to the type and the pop-up will exit.		* If this is a '''Cancel''' button, the changes will not be saved, the confirm attribute will be set to the type and the pop-up will exit.
	In all cases, if the Confirm attribute is present on the button, a Yes/No confirmation message will be displayed before the actions, displaying the message configured on the device. If the user chooses Yes, the actions above will be taken. If the user chooses No, they will be returned to the pop-up screen.		In all cases, if the Confirm attribute is present on the button, a Yes/No confirmation message will be displayed before the actions, displaying the message configured on the device. If the user chooses Yes, the actions above will be taken. If the user chooses No, they will be returned to the pop-up screen.