Bug #19260
closed
Project Listing shows collections incorrectly as "Public Favourites"
Description
I noticed that some collections created by a currently running workflow are shown as public favourite
I tried to unset this but it's still shown afterwards. These collections also don't sho pu in the "Public Favourites" list.
In addition I was not able to open the "Advanced" menu for this collection.
This error is shown in the console:
Files
Updated by Peter Amstutz about 2 years ago
- Target version set to 2022-12-07 Sprint
Updated by Peter Amstutz about 2 years ago
I'm seeing this here:
This is on the "Shared with me" listing.
It does not appear in the "Public favorites" or "My favorites" listings (and I never made it a favorite).
Updated by Stephen Smith about 2 years ago
- Status changed from New to In Progress
Updated by Peter Amstutz about 2 years ago
- Target version changed from 2022-12-07 Sprint to 2022-12-21 Sprint
Updated by Peter Amstutz about 2 years ago
- Assigned To changed from Stephen Smith to Peter Amstutz
Updated by Peter Amstutz about 2 years ago
I think this is not actually a workbench 2 bug, I think what is happening is that because it makes a query with a long list of UUIDs, the query is sent with the parameters as a MIME-encoded attachment, and there is a bug in 2.4 where those are not processed. As a result, it returns an unfiltered list of link objects, and then incorrectly recognizes other link objects (that shouldn't have been returned) as "favorites".
I'm trying to figure out if we fixed the parameter handling in 2.5.
Updated by Peter Amstutz about 2 years ago
- Status changed from In Progress to Resolved
Correction, this IS a workbench 2 bug, just not one specific to "favorites" handling.
Confirmed the underlying cause was that "too big" queries in workbench 2 (which switch from GET to POST with _method=GET) were broken in 2.4 (multipart parameters were ignored), this was fixed in 0095829c16c9756ca03a278687a89fafe2870f86 of ticket #18979
Since this bug was caused by the same underlying bug, it is also fixed. Confirmed in the debugger that it is sending the query correctly and getting the correct result back.