search

opensupplyhub / open-apparel-registry

An application for searching, matching, uploading factories.
MIT License
32 stars 13 forks source link

List approval workflow status updates are needed. Rejected lists to become "inactive". Replaced lists to become "rejected". #2326

Closed vrwOAR closed 1 year ago

vrwOAR commented 1 year ago

Overview

In the new upload workflow, contributor lists are reviewed by OS Hub team. When rejected, the list will stop progressing through the workflow and a rejection message is delivered to the contributor. Though rejected, the lists are maintaining their active status in the list source dashboard and thus remain on the front end as an available list for said contributor. The list details (list name and description) are available, however, the facilities and all corresponding facility data points are not available; as the list was rejected prior to geocoding and matching.

Also, as a part of the upload process, a user has historically had the option to replace a previously uploaded list. Lists uploaded to OS Hub that are replaced with a new upload are being made inactive. However, their status within the Django facility list details remains as “Pending”. Therefore the list remains visible within both the OS Hub Dashboard & the user’s dashboard as a pending list awaiting inputs from the OS Hub admin.

Expected Behavior

Actual Behavior

Steps to Reproduce

Rejected List items:

Inactive Pending List items:

Demo

From staging, here is the view as a user with an upload & replacement:

Additional context

Rejection error: Is occurring with all rejected lists, however, most have been manually updated to reflect accurate records on the platform's front-end. These are the rejected lists currently displaying the error:

Replaced Lists: Replaced lists that should be updated to a status of “rejected”:

obrienad commented 1 year ago

@mariel-oar removed CAN tag because you greenlit it.

vrwOAR commented 1 year ago

@obrienad we're going to add an element to this ticket. Replaced lists are deactivated when the user uploads the new list, however, they aren't being processed as a rejection and thus hang in the pending status as a list awaiting an OS Hub response. I'll flush out the elements this afternoon.

vrwOAR commented 1 year ago

@obrienad, here's the updates to the ticket:

Overview: As a part of the upload process, a user has historically had the option to replace a previously uploaded list. Lists uploaded to OS Hub that are replaced with a new upload are being made inactive. However, their status within the Django facility list details remains as “Pending”. Therefore the list remains visible within both the OS Hub Dashboard & the user’s dashboard as a pending list awaiting inputs from the OS Hub admin.

Expected Behavior: When a list previously uploaded to OS Hub is replaced by the user, the status should be updated to “inactive” and “rejected”. It is not necessary to send the rejected notification to the user for this use case, as they have already replaced the list with another upload that is being processed.

Additional Context: Current list of replaced lists that should be updated to a status of “rejected”:

From staging, here is the view as a user with an upload & replacement:

obrienad commented 1 year ago

thanks, @vrwOAR - is the update meant to replace the body of the original issue? Or be in addition to it? If so, I'll delete the original to avoid confusion / conflicting info.

mariel-oar commented 1 year ago

@obrienad , Vanessa is calling out that there is a second, slightly nuanced case where this list-not-being-rejected behavior happens : (1) when a pending list is rejected, it needs to rejected on the list's source page as well so that it does not show up on the front end and (2) when a pending list gets replaced by a user (before it is approved or rejected by OS Hub), the list needs to go into inactive and rejected status - right now it is only going into inactive. In the second case, the reject email does not need to be sent because the user is essentially rejecting their own list.

(1) is captured in original ticket stop; (2) was not captured in the original ticket, but is very closely related to it.

We will update the original ticket to include both. @vrwOAR, do you mind doing that? It would be good to keep the lists of lists separate for the two use cases at the bottom in the extra context section.

vrwOAR commented 1 year ago

@obrienad & @mariel-oar, I've updated the ticket.

jwalgran commented 1 year ago

Thanks for the update. I would like to discuss at an upcoming check in meeting our options for updating workflow status. I would like to find a way to fix the moderation workflow while reserving the "rejected" status for lists that were never processed and use another method or designation for old lists that have been replaced.

jwalgran commented 1 year ago

In our check-in we agreed to use a distinct status rather than setting previous lists to rejected (either a "real" REPLACED status or a meta status based on the existing replacement tracking)

We need to make sure that in both the moderation UI and the public UI show the active, non-replaced lists.