Skip to content

[OBPIH-6626] [Bug-Fix] Prevent multiple full outbound imports from happening#4791

Merged
awalkowiak merged 2 commits intofeature/outbound-importfrom
OBPIH-6626-finish-button-duplicates-the-request-in-full-outbound-import
Aug 19, 2024
Merged

[OBPIH-6626] [Bug-Fix] Prevent multiple full outbound imports from happening#4791
awalkowiak merged 2 commits intofeature/outbound-importfrom
OBPIH-6626-finish-button-duplicates-the-request-in-full-outbound-import

Conversation

@drodzewicz
Copy link
Collaborator

@drodzewicz drodzewicz commented Aug 19, 2024

✨ Description of Change

A concise summary of what is being changed. Please provide enough context for reviewers to be able to understand the change and why it is necessary. If the issue/ticket already provides enough information, you can put "See ticket" as the description.

Link to GitHub issue or Jira ticket: OBPIH-6626

Description:
TLDR; of the issue: After submitting the full outbound request user is waiting for the redirect to happen and is able to click "Finish" button since after first submit it is not disabled and as a result for each click submits a "NEW" full outbound stock movement.

My solution was to display the spinner overlay which should prevent the user from interacting with the UI while the request is being processed.


📷 Screenshots & Recordings (optional)

If this PR contains a UI change, consider adding one or more screenshots here or link to a screen recording to help reviewers visualize the change. Otherwise, you can remove this section.

image


📈 Test Plan

We require that all code changes come paired with a method of testing them. Please select which of the following testing approaches you've included with this change:

  • Frontend automation tests (unit)
  • Backend automation tests (unit, API, smoke)
  • End-to-end tests (Playwright)
  • Manual tests (please describe below)
  • Not Applicable

Description of test plan (if applicable):


✅ Quality Checks

Please confirm and check each of the following to ensure that your change conforms to the coding standards of the project:

  • The pull request title is prefixed with the issue/ticket number (Ex: [OBS-123] for Jira, [#0000] for GitHub, or [OBS-123, OBPIH-123] if there are multiple), or with [N/A] if not applicable
  • The pull request description has enough information for someone without context to be able to understand the change and why it is needed
  • The change has tests that prove the issue is fixed / the feature works as intended

@drodzewicz drodzewicz self-assigned this Aug 19, 2024
@github-actions github-actions bot added the domain: frontend Changes or discussions relating to the frontend UI label Aug 19, 2024
// If the save went sucessfully, redirect to the stock movement view page
window.location = STOCK_MOVEMENT_URL.show(response.data?.data?.id);
} catch (e) {
spinner.hide();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this hide only in the catch block? What happens if everything goes well?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if everything goes well we are going to get redirected to the show page of the stock movement.

When we call

window.location = STOCK_MOVEMENT_URL.show(response.data?.data?.id);

it still takes some time and if we hide the spinner overlay before redirecting, then user will still be able to click the finish button and the issue will not be resolved.
I decided to keep the show overlay until we are redirected, I believe this looks like a natural behavior for the user - it's like after clicking finish we are waiting for the show page to load.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the hide should be called in the finally. Because of redux-persist we might then come back to the React page with the show state of the spinner.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spinner is blacklisted and is not stored in the redux-presist

Copy link
Collaborator

@kchelstowski kchelstowski Aug 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I was too lazy to check it myself, so thanks for confirming.

@awalkowiak awalkowiak merged commit 1f923c0 into feature/outbound-import Aug 19, 2024
@awalkowiak awalkowiak deleted the OBPIH-6626-finish-button-duplicates-the-request-in-full-outbound-import branch August 19, 2024 15:45
@kchelstowski
Copy link
Collaborator

one comment above

@kchelstowski
Copy link
Collaborator

Moreover I think that the backend should also prevent it. I had that in mind, but since I focused on happy case, I didn't make such validations, but I strongly believe we should also have some kind of "if shipment exists, do not allow to create", etc.
I will try to have that in mind when doing final cleanup.

@drodzewicz
Copy link
Collaborator Author

@kchelstowski I might be wrong but I am not sure how would that be possible? is there any identifier that we can use to say that this outbound is already created? But I don't think so...
From my perspective backend is working properly, until the very last step we are not modifying an existing stock movement but creating a new one based on the provided parameters

@kchelstowski
Copy link
Collaborator

@drodzewicz after adding the spinner, it won't be possible from the frontend perspective, and what I meant is rather something "nice to have" especially if we ever want to support editing an outbound through that workflow - this would then require refactor of API to make additional checks, but we can live without that for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

domain: frontend Changes or discussions relating to the frontend UI

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants