Bug 8125

Summary:	Filter does not work as expected after clearing the search results
Product:	[Build System, Metadata & Runtime] Toaster	Reporter:	Cristina Agurida <cristina-danielax.agurida>
Component:	toaster	Assignee:	Michael Wood <michael.g.wood>
Status:	RESOLVED DUPLICATE	QA Contact:	Cristina Agurida <cristina-danielax.agurida>
Severity:	normal
Priority:	Medium	CC:	alexandru.c.georgescu, alexandru.damian, belen.barros.pena, bluelightning, cristiana.voicu, jessica.zhang, stanciux.mihail
Version:	1.9
Target Milestone:	2.2
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	Regression (Used to work)
Verified:		Documentation change:	No (bug/feature does not impact docs)

Description Cristina Agurida 2015-08-07 09:38:59 UTC

STATUS: FAILED
BUILD: 1.9_M2.rc1: 22078d5e533e59a9aa6999abefbf6ece4e01de8d
ENVIRONMENT: Ubuntu 15.04 x86_64

STEPS TO REPRODUCE: 

1. Open Toaster in managed mode.
2. Create a project.
3. Go to the project page.
4. Select "Layers" table.
5. Run a search (eg: lib).
6. Apply a filter in "Add | Delete" column.
7. Press "Remove search" button.

Expected result:

Both search results and applied filter are cleared, and the table shows all the compatible layers.

Actual outcome:

The filter remains active.
This also happens in "Recipes" and "Machines" tables.

Comment 1 Belen Barros Pena 2015-08-19 15:33:09 UTC

I need to look into this behaviour

Comment 2 Belen Barros Pena 2015-08-20 13:12:15 UTC

Just looked at this, and I think Cristina is right. If we can, we should change the behaviour of ToasterTables to clear any filters applied when you click the 'remove search' button, if only to keep Toaster behaviour consistent across pages (right now, the original tables behave like this, but the ToasterTables tables don't). 

This is probably not a medium+ bug though.

Comment 3 Alexandru Georgescu 2016-02-04 09:58:15 UTC

seems that the issue still exists in YP 2.1_M2.rc1
master/3d2c0f5902cacf9d8544bf263b51ef0dd1a7218c

Comment 4 Belen Barros Pena 2016-04-25 15:51:06 UTC

This is a duplicate of bug 8860

*** This bug has been marked as a duplicate of bug 8860 ***