JMurk / Valve_Hydrant_Mobile_Issues

Water Valve Status Mobile Issues
0 stars 0 forks source link

Hydrant Status: need ability to remove photo #50

Open rssidlowski opened 8 years ago

rssidlowski commented 8 years ago

Need the ability to remove photos that were uploaded.

yousifmalik commented 8 years ago

Completed and ready for testing on DEV

rssidlowski commented 8 years ago

I tested this and the delete is not working correctly. Steps to recreate: 1) opened existing inspection. 2) added photo - jellyfish 3) deleted photo - jellyfish 4) added new photo - penguins photodel1

5) view new photo - should be penguins, but shows jellyfish photodel2

I tried clicking the 'refresh' button and still have same result.

rssidlowski commented 8 years ago

To further clarify. This works correctly if select the photo and the photo name gets refreshed. Not clear what the 'refresh' button does, as after deleting an item and refreshing, the photo name, select image/choose files still has the 'old' item.

yousifmalik commented 8 years ago

Completed and ready for testing on DEV

slmessier commented 8 years ago

Please reference the following graphic and implement the security constraints indicated for each of the 2 cases:

  1. Editor User case
  2. Read Only User case

image

yousifmalik commented 8 years ago

Updated DEV, Could you confirm the work flow is applied to all cases?

slmessier commented 8 years ago

Hi Yousif - I can confirm that the photos screen - including all of its buttons/controls - does appear correctly for the initial screen for both cases (Editor & Read-only). I am also able to successsfully upload a photo.

However I am unable to select a photo.currently so I am unable to test the full wortkflow. Instead of showing a slelected photo. the tap/click "sticks" until the user clicks/taps again. Please see the graphic below for an example of the issue: photo_stick

Please update the system to allow the user to make a photo selection. After the user selects a photo, the system should display the photo's metadata information, enable buttons appropriately, and otherwise respond according to the workflow graphic (repeated below - identical to previous comment) image

slmessier commented 8 years ago

Please find the following instructions below which have been updated to account for pre-existing code that could be leveraged to resolve this issue:

  1. Equivalent functionality exists within the DEVELOPMENT Utility Viewer Mobile App – Add Discrepancy Function. The repository for this code can be identified within the City of Baltimore - EXT Development Wiki page - https://github.com/kcigeospatial/CityOfBaltimore/wiki/Ext-Development** Example of Utility Viewer Functionality: utilityviewer_selectphoto
  2. However, this pre-existing code does not account for the 2 security cases (Editor VS Read-only) that is required for the Valves & Hydrants application. For Valves & Hydrants app, this functionality should be updated to satisfy the specifications within the workflow graphic (reattached without modification below): image
slmessier commented 8 years ago

Hi Yousif - @taojun545 has helped me to update specifications for this issue with updated details. Please review the instructions within most recent comment (above) and let me know if you have additional questions. Otherwise please move forward with developing the outlined updates.

yousifmalik commented 8 years ago

Code updated to DEV. Please confirm the work-flow is working ok. Hint: I used 'locate' tool -> assets and search for hydrant id 216C007760 for my testing.

I do not have access to wiki.

slmessier commented 8 years ago

Hi Yousif - i was able to successfully verify that the system now allow me to upload multiple photos.

However, I am still unable to fully test the associated workflow because the "sticky" map click issue prevents me from selecting a photo (as indicated below). Please investigate the erroneous system behavior, and correct the system to select the thumbnail the user has clicked on and then otherwise following the documented workflow (above). photo_stick

To recreate the issue: access the photo screen for a hydrant with an existing photo (or add a new photo), and then click/tap on an image thumbnail. After the click, the system response erroneously drags/scrolls the screen instead of displaying the thumbnail as selected.

yousifmalik commented 8 years ago

Code fixed and updated on DEV. Can you test the work-flow again and let me know ASAP? I need to refactor the code for these fixes.

slmessier commented 8 years ago

Hi Yousif - i can confirm the issue related to the mouse click/tap has been successfully validate. The photo functionality is looking a lot better at this point. However, when attempting to test all facets of the worfklow, I still encounter the following issues that require an update:

  1. For the Remove Photo workflow, the system currently does not clear the photo metadata information for the removed photo. After the user clicks on the remove button, please update the system to also clear all text from the photo metadata text field(s). image
  2. When 0 photo attachments exist for an inspection, the system should always resort to the "default" photo screen display (see graphic below) - even when 0 photos exist as an outcome of the user removing all previously attached photos. This currently does not occur, (the View and Remove buttons remain enabled for instance) Please update the system logic to have awareness of when 0 photos exist - including the case that exists within the _Remove Workflow) using the previously defined graphic specifications image
yousifmalik commented 8 years ago

Code undated on DEV, Please confirm the changes.

slmessier commented 8 years ago

I was able to successfully validate the full workflow using the DEV application. Issue will be marked as "Ready for Production".

slmessier commented 8 years ago

@yousifmalik and @taojun545 thank you for your patience and coordination in working through the photographs functionality. Please note the specifications and validated photo functionality described within this issue for potential future reference when reconciling code ancestry.