Uploaded image for project: 'IGB'
  1. IGB
  2. IGBF-2081

Returning from the submit app page without submitting app creates entry in Pending app table

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:

      Description

      Steps to reproduce the issue:
      1) Click on submit your app
      2) Select an app to submit from "Choose File" option or Enter URL
      3) Go back to the home page or click browser back button without submitting the app

      This will create an entry in the pending apps table even if the app is not submitted for the release. Also, this will save the jar file for the app in pending_releases folder in s3 bucket.

      Also, if the error page "Something is wrong" is displayed while submitting the app, the app entry will still be created in the AppPending table which can result in improper release of the app without user's approval.

        Attachments

          Issue Links

            Activity

            Hide
            ann.loraine Ann Loraine added a comment -

            1) Regarding issue of two I/O operations on the database:

            I am OK with this. I don't anticipate there will be a large number of users attempting to submit apps to App Store. There will likely be a maximum of 100 such transactions per day.

            2) Regarding multiple entries in pending apps:

            The first time a pending app is added to the database – after the user clicks "upload" the first time – an entry is made in the database.

            At that point, its "user_approved" flag is the default value of false.

            During the upload step, we should add some logic that first attempts to retrieve a pending App with the same coordinates before saving to the database.

            More specifically, the steps would proceed like this - would this work?

            1) User clicks "upload" to send a jar file to our site for processing
            2) Jar file is parsed by our site to determine App Bundle_SymbolicName and Bundle_Version
            3) Our code queries the database to determine if a row with identical values already exists in the database – all values captured in our database table, not just values extracted from the jar file itself, would need to be compared. This includes the jar file itself, which I believe is being saved in the database as a Django-specific object of some type. Our code that makes the comparison will need to be smart enough to handle this data type correctly.
            4) If the row already is there, we do not create a new one. If not, we create a new row with the new values.

            An out-of-scope thought related to this:
            For safety and sanity, I feel like we should also save a unique string signature for the jar file being uploaded - a checksum.

            Show
            ann.loraine Ann Loraine added a comment - 1) Regarding issue of two I/O operations on the database: I am OK with this. I don't anticipate there will be a large number of users attempting to submit apps to App Store. There will likely be a maximum of 100 such transactions per day. 2) Regarding multiple entries in pending apps: The first time a pending app is added to the database – after the user clicks "upload" the first time – an entry is made in the database. At that point, its "user_approved" flag is the default value of false. During the upload step, we should add some logic that first attempts to retrieve a pending App with the same coordinates before saving to the database. More specifically, the steps would proceed like this - would this work? 1) User clicks "upload" to send a jar file to our site for processing 2) Jar file is parsed by our site to determine App Bundle_SymbolicName and Bundle_Version 3) Our code queries the database to determine if a row with identical values already exists in the database – all values captured in our database table, not just values extracted from the jar file itself, would need to be compared. This includes the jar file itself, which I believe is being saved in the database as a Django-specific object of some type. Our code that makes the comparison will need to be smart enough to handle this data type correctly. 4) If the row already is there, we do not create a new one. If not, we create a new row with the new values. An out-of-scope thought related to this: For safety and sanity, I feel like we should also save a unique string signature for the jar file being uploaded - a checksum.
            Hide
            rpatil14 Riddhi Jagdish Patil (Inactive) added a comment -

            Fixed multiple entry creation issue in AppPending table in case of browser back button pressed while submitting app
            https://bitbucket.org/rpatil14/appstore_riddhi/branch/IGBF-2081-BugFix#diff

            Also, added field "updated" to AppPending table which updates the timestamp of app in case of re-submission.

            For below comment,
            "For safety and sanity, I feel like we should also save a unique string signature for the jar file being uploaded - a checksum."
            We are replacing the jar file in S3 bucket if the app is in pending state and submitted multiple times, thus unique string is not required as the old jar is replaced by the new jar as long as it is in pending state.

            cc. [~aloraine]

            Show
            rpatil14 Riddhi Jagdish Patil (Inactive) added a comment - Fixed multiple entry creation issue in AppPending table in case of browser back button pressed while submitting app https://bitbucket.org/rpatil14/appstore_riddhi/branch/IGBF-2081-BugFix#diff Also, added field "updated" to AppPending table which updates the timestamp of app in case of re-submission. For below comment, "For safety and sanity, I feel like we should also save a unique string signature for the jar file being uploaded - a checksum." We are replacing the jar file in S3 bucket if the app is in pending state and submitted multiple times, thus unique string is not required as the old jar is replaced by the new jar as long as it is in pending state. cc. [~aloraine]
            Hide
            ann.loraine Ann Loraine added a comment -
            Show
            ann.loraine Ann Loraine added a comment - I agree Riddhi Jagdish Patil
            Show
            rpatil14 Riddhi Jagdish Patil (Inactive) added a comment - Pull request submitted: https://bitbucket.org/lorainelab/appstore/pull-requests/152/igbf-2081-bugfix/diff
            Hide
            pbole Pawan Bole (Inactive) added a comment -

            Tested all the scenarios, everything is working as expected.

            Show
            pbole Pawan Bole (Inactive) added a comment - Tested all the scenarios, everything is working as expected.

              People

              • Assignee:
                rpatil14 Riddhi Jagdish Patil (Inactive)
                Reporter:
                rpatil14 Riddhi Jagdish Patil (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: