Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Acquisitions: adding a receipt line right after order leads to an error 403 #3414

Open
PascalRepond opened this issue Jul 24, 2023 · 3 comments
Assignees
Labels
bug Breaks something but is not blocking client request Issue reported by production libraries f: acquisitions Related to the acquisition module

Comments

@PascalRepond
Copy link
Contributor

PascalRepond commented Jul 24, 2023

Bug description:

When trying to do an acquisition reception a short time after having performed the acquisition order, it often leads to an error 403. Moreover, the "Receipt" tab is not available after sending an order unless the page is reloaded.

Expected behavior:

I should be able to add a receipt line even if I just sent the acquisition order, without having to wait or reloading the page.

Steps to Reproduce:

  1. Create an acquisition order with a document
  2. Send the order.
  3. See that the "Receipt" tab stays unavailable until I reload the page
  4. Reload the page and go to the Receipt tab
  5. Click on "add"
  6. See error 403

Version:

v1.18.0

Anything else?

Might be linked to the reindexing that takes some time?

@PascalRepond PascalRepond added bug Breaks something but is not blocking f: acquisitions Related to the acquisition module labels Jul 24, 2023
@PascalRepond PascalRepond changed the title Acquisitions: Adding a receipt line right after order leads to an error 403 Acquisitions: adding a receipt line right after order leads to an error 403 Jul 24, 2023
@PascalRepond PascalRepond moved this from Inbox to Product Backlog in RERO ILS issues Jul 24, 2023
@PascalRepond PascalRepond added the client request Issue reported by production libraries label Jul 25, 2023
@zannkukai zannkukai self-assigned this Jul 27, 2023
@zannkukai zannkukai moved this from Product Backlog to In Development in RERO ILS issues Jul 27, 2023
@zannkukai
Copy link
Contributor

zannkukai commented Jul 27, 2023

random behavior, seems due to order reindexing

When sending on order, the backend will generate a notification. If the notification dispatch is successful, order-lines and order are update and reindex. This behavior seems synchronous (it must be!) https://github.com/rero/rero-ils/blob/staging/rero_ils/modules/acquisition/acq_orders/api.

UI behavior is based on ES index (order status is only stored/process for ES). If the order status is still "PENDING" (not yet indexed as "ORDERED") then the receipt tab will be disabled. Same if user try to access the receipt URL : the guard check is order status is valid : https://github.com/rero/rero-ils-ui/blob/staging/projects/admin/src/app/acquisition/routes/guards/can-order-receipt.guard.ts#L87-L108

@zannkukai zannkukai moved this from In Development to Product Backlog in RERO ILS issues Jul 27, 2023
@zannkukai zannkukai removed their assignment Jul 27, 2023
@PascalRepond PascalRepond moved this from Product Backlog to Sprint backlog in RERO ILS issues Nov 20, 2023
@PascalRepond PascalRepond moved this from Sprint backlog to Product Backlog in RERO ILS issues Nov 20, 2023
@PascalRepond
Copy link
Contributor Author

Re-upping this issue as it is quite annoying for users. Either:

  • Make the notification dispatcher instant (check if there is a grouping and notifs are sent only every X minutes)
  • Do not wait for a notification sent confirmation but only for notification dispatch to reindex resources

We must find a way to allow receipts to be performed right after having sent an order, or at least without having to wait for several minutes!

PascalRepond added a commit to PascalRepond/rero-ils that referenced this issue Nov 30, 2023
* Closes rero#3414.

Co-Authored-by: Pascal Repond <pascal.repond@rero.ch>
@PascalRepond PascalRepond moved this from Product Backlog to In Development in RERO ILS issues Nov 30, 2023
@PascalRepond PascalRepond self-assigned this Nov 30, 2023
PascalRepond added a commit to PascalRepond/rero-ils that referenced this issue Nov 30, 2023
* Closes rero#3414.

Co-Authored-by: Pascal Repond <pascal.repond@rero.ch>
@PascalRepond PascalRepond moved this from In Development to Ready to test in RERO ILS issues Nov 30, 2023
@PascalRepond PascalRepond moved this from Ready to test to Product Backlog in RERO ILS issues Dec 20, 2023
@PascalRepond
Copy link
Contributor Author

Still cannot reproduce consistently, which means it is very difficult to fix.

@PascalRepond PascalRepond moved this from Product Backlog to Inbox in RERO ILS issues Mar 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Breaks something but is not blocking client request Issue reported by production libraries f: acquisitions Related to the acquisition module
Projects
Status: Inbox
Development

Successfully merging a pull request may close this issue.

2 participants