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

            rpatil14 Riddhi Jagdish Patil (Inactive) created issue -
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Field Original Value New Value
            Epic Link IGBF-1388 [ 17463 ]
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Link This issue blocks IGBF-2026 [ IGBF-2026 ]
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Summary Returning from the page without submitting app creates entry in Pending app table Returning from the submit app page without submitting app creates entry in Pending app table
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Status To-Do [ 10305 ] In Progress [ 3 ]
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Assignee Riddhi Jagdish Patil [ rpatil14 ]
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            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 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.
            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.
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            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.
            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, 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.
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Labels Advanced
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Story Points 1 2
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            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, 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.
            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.
            Hide
            ann.loraine Ann Loraine added a comment -

            Suggestion for how to address this problem:

            Add a new boolean value field to AppPending class in submit_ap/models.py:

            • submitter_approved - can be True, False, default is False.

            How this would work:

            When user clicks "Next" on the "submit app" page UI, then App Store creates an entry in the AppPending table for the App. This is already being done. What's new is that the new row of data will include "submitter_approved" field set to False, the default.

            Next, App Store displays the pre-submission feedback page, which shows information about this "pending" App.

            If the user clicks "Submit", then "submitter_approved" changes to "True", along with other actions already being performed, such as sending an email to the user and to our app approvers ("admin" users).

            If the user clicks "Cancel", then the row is deleted from the database and the uploaded jar file gets removed from the system.

            If the user does nothing, then the field "submitter_approved" remains False.

            Separately, we implement a data clearing mechanism that removes all stale AppPending rows (and jar files) with false "submitter_approved" and "created" dates older than a pre-set amount, e.g., 24 hours.

            If a user gets distracted or disrupted during this process, they might repeat the app submission process from the beginning (most likely) or might return directly to this feedback page if it is still open.

            If they repeat the process from the beginning before we get around to clearing out the old, stale data, then the previously uploaded jar file and the previously created entry in the pending apps database table will simply be over-written.

            If they come back to the "feedback" page and click "Submit" after we have cleared the data, then we display a page that says something like "Sorry, this App is not longer in our system because too much time has passed since you first uploaded it. No problem! Please go back and try again."

            Also, our admin users who can approve apps should only see Apps that have been approved by their submitter - i.e., submitter_approved is True. All other Apps could be shown in a different category on that page, or we could not show them at all. If somebody has changed their mind about submitting and an App or is maybe not sure they want to submit it, we should probably ignore it.

            I think we should do something like the above rather than add more complexity to the system by using cookies and introducing state to user's browsers. Also, if we start using cookies, we have to show a disclaimer, which I feel are a bit annoying and distracting.

            Show
            ann.loraine Ann Loraine added a comment - Suggestion for how to address this problem: Add a new boolean value field to AppPending class in submit_ap/models.py: submitter_approved - can be True, False, default is False. How this would work: When user clicks "Next" on the "submit app" page UI, then App Store creates an entry in the AppPending table for the App. This is already being done. What's new is that the new row of data will include "submitter_approved" field set to False, the default. Next, App Store displays the pre-submission feedback page, which shows information about this "pending" App. If the user clicks "Submit", then "submitter_approved" changes to "True", along with other actions already being performed, such as sending an email to the user and to our app approvers ("admin" users). If the user clicks "Cancel", then the row is deleted from the database and the uploaded jar file gets removed from the system. If the user does nothing, then the field "submitter_approved" remains False. Separately, we implement a data clearing mechanism that removes all stale AppPending rows (and jar files) with false "submitter_approved" and "created" dates older than a pre-set amount, e.g., 24 hours. If a user gets distracted or disrupted during this process, they might repeat the app submission process from the beginning (most likely) or might return directly to this feedback page if it is still open. If they repeat the process from the beginning before we get around to clearing out the old, stale data, then the previously uploaded jar file and the previously created entry in the pending apps database table will simply be over-written. If they come back to the "feedback" page and click "Submit" after we have cleared the data, then we display a page that says something like "Sorry, this App is not longer in our system because too much time has passed since you first uploaded it. No problem! Please go back and try again." Also, our admin users who can approve apps should only see Apps that have been approved by their submitter - i.e., submitter_approved is True. All other Apps could be shown in a different category on that page, or we could not show them at all. If somebody has changed their mind about submitting and an App or is maybe not sure they want to submit it, we should probably ignore it. I think we should do something like the above rather than add more complexity to the system by using cookies and introducing state to user's browsers. Also, if we start using cookies, we have to show a disclaimer, which I feel are a bit annoying and distracting.
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Link This issue is blocked by IGBF-2087 [ IGBF-2087 ]
            Hide
            rpatil14 Riddhi Jagdish Patil (Inactive) added a comment - - edited

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

            Solution:
            Add a field "submitter_approved" to AppPending model and set its value to "True" only if the user submits the app for release. Based on the value of this field Pending apps dashboard will be populated so that only the apps which are submitted by the user are released.

            Files changed:
            submit_app/models.py
            submit_app/templates/error.html
            submit_app/templates/upload_form.html
            submit_app/views.py
            Code changes are present in branch https://bitbucket.org/rpatil14/appstore_riddhi/branch/IGBF-2081#diff

            Testing steps:
            Scenario 1:
            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
            Entry should be created in the AppPending table with submitter_approved value as "False". And the Pending apps page should not display this app.

            Scenario 2:
            1) Click on submit your app
            2) Select an app to submit from "Choose File" option or Enter URL
            3) Submit the app by clicking "It's all good. Submit my app" button
            Entry should be created in the AppPending table with submitter_approved value as "True". And the Pending apps page should display this app.

            Scenario 3:
            1) Click on submit your app
            2) Select an app to submit from "Choose File" option or Enter URL
            3) Cancel app submission by clicking "No. Cancel submission and go back" button
            Entry should not be created in the AppPending table and the Pending apps page should not display this app.

            Scenario 4:
            1) Click on submit your app
            2) Select an app to submit from "Choose File" option or Enter URL
            3) Submit the app and then submit another version of same app
            Entry should not be created in the AppPending table and the Pending apps page should not display this app.

            Testing results:
            Code changes are deployed to https://dev-appstore-6.bioviz.org. Admin username and password for devappstore6 is same as devappstore2

            Next steps:
            Jira ticket IGBF-2087
            Implement data cleaning mechanism to remove stale entries from AppPending table whose submitter_approved field is "False" and remove jar files from S3 bucket for the apps which are not approved by the submitter to release.

            cc. [~aloraine]

            Show
            rpatil14 Riddhi Jagdish Patil (Inactive) added a comment - - edited Issue: Returning from the submit app page without submitting app creates entry in Pending app table Solution: Add a field "submitter_approved" to AppPending model and set its value to "True" only if the user submits the app for release. Based on the value of this field Pending apps dashboard will be populated so that only the apps which are submitted by the user are released. Files changed: submit_app/models.py submit_app/templates/error.html submit_app/templates/upload_form.html submit_app/views.py Code changes are present in branch https://bitbucket.org/rpatil14/appstore_riddhi/branch/IGBF-2081#diff Testing steps: Scenario 1: 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 Entry should be created in the AppPending table with submitter_approved value as "False". And the Pending apps page should not display this app. Scenario 2: 1) Click on submit your app 2) Select an app to submit from "Choose File" option or Enter URL 3) Submit the app by clicking "It's all good. Submit my app" button Entry should be created in the AppPending table with submitter_approved value as "True". And the Pending apps page should display this app. Scenario 3: 1) Click on submit your app 2) Select an app to submit from "Choose File" option or Enter URL 3) Cancel app submission by clicking "No. Cancel submission and go back" button Entry should not be created in the AppPending table and the Pending apps page should not display this app. Scenario 4: 1) Click on submit your app 2) Select an app to submit from "Choose File" option or Enter URL 3) Submit the app and then submit another version of same app Entry should not be created in the AppPending table and the Pending apps page should not display this app. Testing results: Code changes are deployed to https://dev-appstore-6.bioviz.org . Admin username and password for devappstore6 is same as devappstore2 Next steps: Jira ticket IGBF-2087 Implement data cleaning mechanism to remove stale entries from AppPending table whose submitter_approved field is "False" and remove jar files from S3 bucket for the apps which are not approved by the submitter to release. cc. [~aloraine]
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Status In Progress [ 3 ] Needs 1st Level Review [ 10005 ]
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Assignee Riddhi Jagdish Patil [ rpatil14 ]
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Story Points 2 1
            ann.loraine Ann Loraine made changes -
            Sprint Fall 5 : 14 Oct to 25 Oct [ 76 ] Fall 5 : 14 Oct to 25 Oct, Fall 6 : 28 Oct to 8 Nov [ 76, 77 ]
            ann.loraine Ann Loraine made changes -
            Rank Ranked higher
            ann.loraine Ann Loraine made changes -
            Status Needs 1st Level Review [ 10005 ] First Level Review in Progress [ 10301 ]
            ann.loraine Ann Loraine made changes -
            Status First Level Review in Progress [ 10301 ] Ready for Pull Request [ 10304 ]
            ann.loraine Ann Loraine made changes -
            Assignee Ann Loraine [ aloraine ]
            ann.loraine Ann Loraine made changes -
            Assignee Ann Loraine [ aloraine ] Riddhi Jagdish Patil [ rpatil14 ]
            Hide
            rpatil14 Riddhi Jagdish Patil (Inactive) added a comment -
            Show
            rpatil14 Riddhi Jagdish Patil (Inactive) added a comment - Pull request submitted: https://bitbucket.org/lorainelab/appstore/pull-requests/145/igbf-2081/diff cc. [~aloraine]
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Status Ready for Pull Request [ 10304 ] Pull Request Submitted [ 10101 ]
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Assignee Riddhi Jagdish Patil [ rpatil14 ]
            ann.loraine Ann Loraine made changes -
            Status Pull Request Submitted [ 10101 ] Reviewing Pull Request [ 10303 ]
            ann.loraine Ann Loraine made changes -
            Status Reviewing Pull Request [ 10303 ] Merged Needs Testing [ 10002 ]
            Hide
            ann.loraine Ann Loraine added a comment -

            Merged.

            Show
            ann.loraine Ann Loraine added a comment - Merged.
            Hide
            ann.loraine Ann Loraine added a comment -
            Show
            ann.loraine Ann Loraine added a comment - Deployed on https://dev-appstore-2.bioviz.org .
            ann.loraine Ann Loraine made changes -
            Status Merged Needs Testing [ 10002 ] Post-merge Testing In Progress [ 10003 ]
            ann.loraine Ann Loraine made changes -
            Status Post-merge Testing In Progress [ 10003 ] Merged Needs Testing [ 10002 ]
            pbole Pawan Bole (Inactive) made changes -
            Assignee Pawan Bole [ pbole ]
            pbole Pawan Bole (Inactive) made changes -
            Status Merged Needs Testing [ 10002 ] Post-merge Testing In Progress [ 10003 ]
            Hide
            pbole Pawan Bole (Inactive) added a comment -

            All the scenarios mentioned by Riddhi Jagdish Patil are working as expected.
            However, if we select the app after choosing or entering the URL and go back to the home page or click the browser back button without submitting the app multiple times, duplicate entries are created.
            Steps to reproduce :
            1) Click on submit your app
            2) Select an app to submit from the "Choose File" option or Enter URL
            3) Go back to the home page or click the browser back button without submitting the app
            4) Follow the above steps multiple times.
            Multiple entries are created in the AppPending table with submitter_approved value as "False".

            Show
            pbole Pawan Bole (Inactive) added a comment - All the scenarios mentioned by Riddhi Jagdish Patil are working as expected. However, if we select the app after choosing or entering the URL and go back to the home page or click the browser back button without submitting the app multiple times, duplicate entries are created. Steps to reproduce : 1) Click on submit your app 2) Select an app to submit from the "Choose File" option or Enter URL 3) Go back to the home page or click the browser back button without submitting the app 4) Follow the above steps multiple times. Multiple entries are created in the AppPending table with submitter_approved value as "False".
            pbole Pawan Bole (Inactive) made changes -
            Status Post-merge Testing In Progress [ 10003 ] To-Do [ 10305 ]
            pbole Pawan Bole (Inactive) made changes -
            Assignee Pawan Bole [ pbole ] Riddhi Jagdish Patil [ rpatil14 ]
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Status To-Do [ 10305 ] In Progress [ 3 ]
            Hide
            rpatil14 Riddhi Jagdish Patil (Inactive) added a comment -

            To prevent multiple entries in the database, we will need to make two I/O operations to the database every time user submits the app. One call to check if the object already exists in the database and next to create or update the actual entry. This can slower the performance of the system in case of above mentioned scenario.

            Multiple entries will be created in the AppPending table but the submitter_approved flag will be false. Admin will not be able to release these apps as it is not approved by the submitter. Also, these entries will be cleared from the database every 24 hours when the data cleaning cron runs.

            So, I believe changing the existing system will impact the performance of system. Do we still me to do this change?

            cc. [~aloraine]

            Show
            rpatil14 Riddhi Jagdish Patil (Inactive) added a comment - To prevent multiple entries in the database, we will need to make two I/O operations to the database every time user submits the app. One call to check if the object already exists in the database and next to create or update the actual entry. This can slower the performance of the system in case of above mentioned scenario. Multiple entries will be created in the AppPending table but the submitter_approved flag will be false. Admin will not be able to release these apps as it is not approved by the submitter. Also, these entries will be cleared from the database every 24 hours when the data cleaning cron runs. So, I believe changing the existing system will impact the performance of system. Do we still me to do this change? cc. [~aloraine]
            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]
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Status In Progress [ 3 ] Needs 1st Level Review [ 10005 ]
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Assignee Riddhi Jagdish Patil [ rpatil14 ]
            Hide
            ann.loraine Ann Loraine added a comment -
            Show
            ann.loraine Ann Loraine added a comment - I agree Riddhi Jagdish Patil
            ann.loraine Ann Loraine made changes -
            Status Needs 1st Level Review [ 10005 ] First Level Review in Progress [ 10301 ]
            ann.loraine Ann Loraine made changes -
            Status First Level Review in Progress [ 10301 ] Ready for Pull Request [ 10304 ]
            ann.loraine Ann Loraine made changes -
            Assignee Riddhi Jagdish Patil [ rpatil14 ]
            Show
            rpatil14 Riddhi Jagdish Patil (Inactive) added a comment - Pull request submitted: https://bitbucket.org/lorainelab/appstore/pull-requests/152/igbf-2081-bugfix/diff
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Status Ready for Pull Request [ 10304 ] Pull Request Submitted [ 10101 ]
            ann.loraine Ann Loraine made changes -
            Status Pull Request Submitted [ 10101 ] Reviewing Pull Request [ 10303 ]
            rpatil14 Riddhi Jagdish Patil (Inactive) made changes -
            Assignee Riddhi Jagdish Patil [ rpatil14 ]
            ann.loraine Ann Loraine made changes -
            Status Reviewing Pull Request [ 10303 ] Pull Request Submitted [ 10101 ]
            ann.loraine Ann Loraine made changes -
            Status Pull Request Submitted [ 10101 ] Reviewing Pull Request [ 10303 ]
            ann.loraine Ann Loraine made changes -
            Status Reviewing Pull Request [ 10303 ] Merged Needs Testing [ 10002 ]
            pbole Pawan Bole (Inactive) made changes -
            Status Merged Needs Testing [ 10002 ] Post-merge Testing In Progress [ 10003 ]
            pbole Pawan Bole (Inactive) made changes -
            Assignee Pawan Bole [ pbole ]
            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.
            pbole Pawan Bole (Inactive) made changes -
            Resolution Done [ 10000 ]
            Status Post-merge Testing In Progress [ 10003 ] Closed [ 6 ]
            pbole Pawan Bole (Inactive) made changes -
            Assignee Pawan Bole [ pbole ] Riddhi Jagdish Patil [ rpatil14 ]

              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: