snipe
Advanced Filterpresets for Listview
Hello,
we want to implement a feature which allows for filterpresets/templates to be used for the listviews. This feature also relates to 12195 but extends it for the ability to save the current search as a template for reusability.
Current situation: Currently advanced filtering can only properly be done with the custom export. Predefined filters are not available for all assets at all.
Goal: The goal with this feature is to provide a reuasble predefined search for filtering the list view without the need to use the custom report Additionally it should be possible to create a shared filtertemplate which can be used by other users
To be discussed:
- Can the templates from custom reports be reused to also serve as filterbasis for the datatables?
- Which problems might occur when reusing them?
- Access rights for specific searches? Maybe based on Roles?
Benefits:
- Easy access to predefined filter
- Reduce dependency on Custom Export
- Speeds up workflow
@snipe We would take over the implementation and contribute to the project, since this is highly requested within our company, however I'd like to discuss with you what can and can not be done, as well as possible solutions.
Hi there - we've tried this several times in the past (as has been discussed here for quite some time) but it's never quite worked and has conflicted with some of the other BS tables plugins.
If you want to give it a shot, you're more than welcome to though. Some sample code is here: #1728.
One of the challenges you'll run into is that for organizations with a LOT of results for, say, locations, you'll need to paginate that list the same way we do elsewhere, or the filters will be very slow.
Hi,
Just wondering - which dimensions would be considered a lot in this case? Like 1k, 10k, 100k, 500k?
We can never know how many of anything someone might have, which is why the select2 pagination+search is necessary. Otherwise you'll end up filling up the DOM with potentially tens of thousands of HTML elements and it will crash out the page. It's why all of our select boxes are ajaxed in via the selectlist controller methods.
Could someone have 100k locations? Yep. Should they is another matter altogether, but we have to account for the fact that it's possible. I've seen people with 10k locations (schools, largely, where they'll use a shelf as a location, and that shelf lives in a closet which is a location, which lives in a room which is a location, which is on a part of a campus which is within a campus which is part of a school, etc etc)
Hi,
To implement the advanced search function, I would need to extend the current API to fetch all the assets (https://snipe-it.readme.io/reference/hardware-list), so that instead of a string, an array with all the searched data can be passed in. It will support both passing a string or an array.
As an alternative, I could add a new endpoint for the advanced search feature. What would be the better solution in your opinion?
I will also extend the unit and feature tests, as well as the documentation.
Snipe-IT DocumentationReturn a listing of assets
Advanced search and column filters are two different things, so I'm not sure which it is you're looking for. We already have advanced search on assets, which uses this code for results:
https://github.com/grokability/snipe-it/blob/032a664d4ceb1c8dcda84fa567305fa013a80b61/app/Models/Asset.php#L1714-L1916
For column filters, for things like location, company, models, etc, we'd need to use the paginated data from the selectlist() methods on each of those API controllers, for example:
https://github.com/grokability/snipe-it/blob/032a664d4ceb1c8dcda84fa567305fa013a80b61/app/Http/Controllers/Api/AssetModelsController.php#L268-L310
We did some prototyping and came to the conclusion that the feature fits better to an updated/extended advanced search.
Current ideas:
- Extend the advanced search in a way so that it works in a similiar way as the custom export does.
- It shall support selection of multiple values as filter criteria for a single field
- it shall provide suggestions based on existing entries when defining a filter critera
- it shall provide a save button which allows to save the currently defined filter as predefined filter
- The UI for the advanced search will be updated to better reflect the new requirements and to improve usability
- Predefined filters
- Predefined filters reflect the searches stored from the advanced search
- They shall be selectable via a dropdownmenu
- When selecting a predefined filter the filters set are being displayed in the advanced search menu, which can then be edited to customize the search even more while still getting results quicker with the predefined filters
Initial Idea was to reuse the templates from custom export but currently we think it is better to create a new datatable which stores the predefined filters, since new fields are needed for access rights. This would also allow to extend and update templates and predefined filters independently in the future.
For the integration of the predefined filters and adaptions to the advanced search some UI changes are necessary. We came up with the following ideas to integrate the new features. (See image)
- The first design implements a hideable side menu which includes a dropdownlist of the predefined filters as well as the advanced search
- The second and third approach each have a dropdown menu above the asset list containing the advanced search, the difference between the two is that the second design has the predefined filter dropdown list inside the advanced search dropdown to show the user that these two are related and interact with each other, whereas ...
- ...the third approach has the dropdownmenu for the predefined filters moved next to the bulk editing menu, to allow for a workflow with less clicks.
@Snipe: Since we are not key users of snipe-it I'd like to get your opion and what you think is the best fitting design for the project. Could you also let us know up to how many custom fields are used in the tool? This is to cover those edgecases as well.
Furthermore we are currently thinking about how we enable management of existing predefined filters. There are currently 2 ideas.
- Provide all functionality to edit/update/save/delete/change rights of predefined filters inside the adapted dropdown menues
- Create a new site under settings (like e.g. locations) which lists all predefined filters and allows for editing and updating specific information.
The second option is currently my prefered one, since it allows for more flexibility and prevents overloading the ui with buttons
There could potentially be hundreds of custom fields. There's no way to know how many people will use. I've definitely seen folks with 100 or more.
After some back and forth, we have agreed on this database structure. Based on your experience, is there anything missing.
Do you have any further suggestions or concerns?
Well I guess I'm trying to understand what you're trying to do here. What's is_public? Does that male them shareable across users in all companies? I think that would need to be companyable as well, since many things (like locations) might not be the same across multiple companies depending on FMCS status.
(Additionally, we'd probably want to store the object type, since people will want this for users and other things and well.)
It does sort of seem like the first, easier step here is to make the existing BS tables advanced search work better and/or use the table filter headers using the list boxes where appropriate. This seems like a big overhaul when BS tables already has some of this functionality built in.
I'll try to explain what we are trying to achieve, but firstly to clear any possible misunderstandings I suppose we have to remove the relation to #1728 since our initial idea involved the table itself with an excel like filtering, but we quickly came to the conclusion that an updated/improved advanced search allows us to more easily implement the key feature we are interested in.
So what exactly are we trying to achieve: They key feature we want to have is predefined filters (Filterpresets as initially called). This is similar to the templates in the custom export view with the difference, that they can be directly applied as filter to the assets table Another difference is that we want to allow predefined filters to be created as shared filters so that other users can also apply those filters. (This is also why the "is_public" flag is needed).
- Everyone can create and save their own predefined_filter
- Some people shall have the right to create shared filters for others to use
-
- This could be e.g. the IT Admin who wants to provide a filter for a specific group which filters for all the assets this group is responsible for
-
- When a user is member of that specific group he will now see the filter defined by the IT Admin
- This demands that the predefined filters need to be linked to specific groups on a per filter basis
- predefined_filters shall also be linkable to multiple groups.
As for the DB tables we included the type filters as mentioned, since I also think this would be a good addition long term.
To be able to create such a filter we had to show some love to the existing advanced search because we needed a few more features which makes the advanced search easier to use and also enables more precise searching. Screenshot of the current status is attached.
We still need to improve the UI for the advanced search a bit as well as to provide the buttons and input fields to be able to save the current search as predefined_filter.
One thing that is not yet visible on the screenshots is the dropdown to select a predefined_filter which shows all filters the current user is eligible to see. These include:
- Filters the user has created himself
- Filters which are shared for any group the user is part of
Hopefully this made things a bit clearer. If not please let me know so that we can explain it even further and answer any upcomming questions.
@snipe we are close to finishing the feature but need yet some answers to the following questions:
- Where and how should new and updated APIs be documented? (Couldn't find anything about it in the "How to contribute")
- Are there any global code formatting rules?
- For UI testing the question arose which resolutions have to be supported?
We are about to start into our testing phase with only a few things that have to be adapted.
@snipe since I don't have the team that is currently working on this issue for much longer I would appreciate some feedback, so that we can still make some changes if needed. We are aiming to be finished at mid of Oct.
Just as a heads up, if there are changes needed or feedback that has to be included at a later time we can most likely not implement those changes ourselves and have to leave it to you or the community to build upon it.
Since I prefer delivering a finished product, that is being accepted by the community I'd really appreciate any feedback that might block, defer, or prevent this feature from being merged into the repository.
As for another update: Here are some new cool features which we think the community will also like.
- Search field to be able to search for any field (Helps especially if you have many custom fields), see images below
- Dropdown for predefined filters
- Fields now support "equals","not equals","contains","not contains" -> Note: The current UI is only for developing purposes and will be improved to only have a small icon which can be used to select the needed usecase
- Example of the currently search which returns all models that contain "macb"
- Search button
- menu button for predefined filter
- To hide the search
- To delete the current search criteria
- To open the filters
Image to illustrate 1:
Image to show 6 - Menu to create update and delete predefined filters
And lastly the settings page for predefined filters. Here you are able to edit the group rights as well as delete the filter. For updating the filter you are currently redirected to the corresponding type (e.g assets) with the filter preselected for updating.
Without seeing the code (or a functioning demo), it's really hard for me to have strong opinions here. Things like Fields now support "equals","not equals","contains","not contains" all sound great, but how is that being handled on the API side of things? How modular is this code? Has it been tested with hundreds of custom fields? Like, this seems like good start, but you're asking me to approve something I cannot see (and will have to maintain in perpetuity) other than some screenshots, and I don't know how aligned the code is as it relates to the directions we're going.
Reviewing this PR is already going to be a beat - trying to review a feature this large without even being able to see any code is impossible - and I'm not sure why the simpler version of having a form-builder search UI at the top of the table that I originally suggested wasn't considered.
Where and how should new and updated APIs be documented? (Couldn't find anything about it in the "How to contribute")
They would go in the PR.
Are there any global code formatting rules?
Not really, and we could fix that in post anyway.
For UI testing the question arose which resolutions have to be supported?
Basically all of them. Mobile compatibility is critical.
I'd probably want the "toggle filters" bit in the table button bar on the right - it takes up a lot of space where it is now.
Here are our changes for the API
- Selectlist for the new dropdown for the assignedTo field: https://github.com/imbus/snipe-it/blob/develop/app/Http/Controllers/Api/AssignedToDropdownController.php
- The endpoint for querying the assets https://github.com/imbus/snipe-it/blob/develop/app/Http/Controllers/Api/AssetsController.php#L60 (the index method)
- Added a selectlist to the groups-controller that only returns the groups where a user is member of https://github.com/imbus/snipe-it/blob/develop/app/Http/Controllers/Api/AssetsController.php#L60
- PredefinedFiltercontroller for managing the predefined filters https://github.com/imbus/snipe-it/blob/develop/app/Http/Controllers/Api/PredefinedFilterController.php
- PredefinedFilterPermissionscontroller to manage the permissions of the predefined filters https://github.com/imbus/snipe-it/blob/develop/app/Http/Controllers/Api/PredefinedFilterPermissionController.php
- Added a new way to show a notification using laravel livewire (was already part of snipe-it) https://github.com/imbus/snipe-it/blob/develop/app/Livewire/Notifications.php#L8-L42
GitHub
A free open source IT asset/license management system - imbus/snipe-it
A free open source IT asset/license management system - imbus/snipe-it
A free open source IT asset/license management system - imbus/snipe-it
A free open source IT asset/license management system - imbus/snipe-it
A free open source IT asset/license management system - imbus/snipe-it
@snipe I've recorded a video of how it looks currently. Please have a look and give us feedback. Whether it is something you'd like to have changed or if another demo with different datasets is needed.
youtube (Had to upload to YT since there is a 10mb limit here.
Info about the VM: CPU: 2 Core (SandyBridge -> Xeon(R) Gold 6342 CPU @ 2.80GHz) RAM: 4GB HD: nvme 1x60GB OS: Ubuntu 22.04 LTS DB: Docker container -> image: mariadb:latest
We are currently fixing some minor bugs, but apart from that it is looking quite promising.
I've also recorded a short demo of how it performs with a lot of Assets Here we have 50k Assets and 167k people
@snipe Could you please provide some feedback until Wednesday next week?
Overall the feature looks good to us. Our QA sessions are also promising, there are only a few things left to fix. The big questionmark is if you need to have anything changed.
https://github.com/user-attachments/assets/a5a02bd3-d3f0-4a43-8c20-67c2567445ae
You folks are really not making this easy for us to give feedback on. This does look promising, but what is the API searching on? What actual changes are happening here? I've been asking to see the code for a while now, because if the changes aren't something we can sustain over time, we can't take them. Do they work with the BS Table cookies and linked URLs? What does this look like on mobile? How can we be sure the code is written securely? The mockups and such are nice (and the demo is certainly quite helpful) but without seeing the code, I can't commit to anything. We'll be the ones having to maintain it when new bugs come up, and the way it's implemented may not even be aligned with how we're architecting things moving forward.
Not to mention the confusion of why there are two things called "Advanced Search" on that page.
@snipe I understand you concerns and our goal is also to have the code alligned with all your demands, that's also the reason I'd like to have feedback, since we don't want to create a new feature which will never be merged/used.
lucas already sent a list with all the changed APIs in a previous comment: here
If you need the code in another format please let us know, then we will provide it in the requested format on Monday. We will also check if anything else has been changed/updated in the meantime and let you know as well.
As for the development we've taken accessability and compatability (mobile) into account.
Specific technical questions can be answered by Lucas and Jonas, they'll be back on Monday.
lucas already sent a list with all the changed APIs in a previous comment: https://github.com/grokability/snipe-it/issues/17494#issuecomment-3371425999
Those are files, not diffs :( It's very difficult to see what's changed in very large files by memory
Thank you - I really appreciate it. This does look like a great feature, and we're excited about it! It's just daunting when you consider what else might possibly break or introduce security issues (full multiple company support, etc), and reviewing a ton of code that we'll end up being responsible for down the line is a big undertaking.
I realize you're probably writing this (or having it written) for a very specific use-case or client, but we always do need to make sure that this code will work moving forward. Even we ourselves often introduce small changes that we're convinced won't negatively impact the community, and we find out (usually very quickly) that certain folks' use-cases (that we didn't even know about) relied on something we changed or fixed.
Not to mention that we're going to be upgrading the entire UI soon, so there are a lot of additional non-user-facing concerns that we as the maintainers have to deal with.
@snipe here is a diff between your and our develop-branch: https://github.com/grokability/snipe-it/compare/develop...imbus:snipe-it:develop?diff=unified&w we will clean up some stuff before the merge.
We developed around 300 Feature- and Unittests and used yours to ensure that nothing breaks.
- For the assets queries: https://github.com/imbus/snipe-it/tree/develop/tests/Feature/AssetQuery
A free open source IT asset/license management system - imbus/snipe-it
I totally get all you concerns especially if there is such a large new feature being introduced.
Therefor I'd like to tell you how we try to mitigate all the identified risks.
- As Lucas has mentioned we have roughly 300 Feature and Unit tests which are being executed automatically each time a feature branch is being merged to our develop branch, which serves as a gate for the merge
- The pipeline is then creating a new docker image which is published on dockerhub and then deployed on our testVM
- On the test VM we are performing manual E2E testcases with each version to check if everything is still working as expected. (We currently have 78 manual testcases)
- Focus of the manual TCs is to ensure correct:
-
- Functionality
-
- Security (Check for SQL Injection, Access rights for different user roles)
-
- Accessability
-
- Compatability (Different Browsers, resolutions, mobile compatability)
-
- Performance (We use different backups to simulate different usecases from few assets with barely any custom fields to very large number of assets and a lot of custom fields locations etc)
- Additionally we also perform some explorative tests
Currently only 2 of the 78 TCs are failed, but the bugs are already being fixed, so overall it is looking quite good from testperspective. If you are interested in more insights for the testing let us know.
I am also looking forward to your feedback regarding the changes we made.
@snipe Is it possible for you to provide some early feedback just so that we know how much work is still ahead of us? If that is not possible a timeframe when we can expect the review remarks would be much appreciated.
Hey @snipe,
we've already created a draft PR and are currently cleaning up some of the stuff codacy complained about.
As for the timeline: The developers of our team will still be available for at least the next 14 days, after that they will be moved to other projects so we won't be able to work full time on this feature. If you have any remarks please let us know in a timely manner, so that we have time to fix these things. Thank you!
As for the testcoverage additional to the unit and feature test we've added we also performed the following manual testcase and some explorative tests based on experience gained previously.
Below is the list of our manual testcases. (If detailed teststeps are needed pls let us know, they'd have to be translated first) The results are all looking good, apart from a few minor bugs which are already being fixed.
| ID | Layer | UserStory | Titel |
|---|---|---|---|
| TC-U1-001 | System/UI | US1 | Filter for Standardfields (Model) |
| TC-U1-002 | System/UI | US1 | Filter for Custom Fields (Text) |
| TC-U1-003 | System/UI | US1 | Multi-Select on Status |
| TC-U1-004 | System/UI | US1 | Filtercombination with multiple fields |
| TC-U1-005 | System/UI | US1 | Auto-Completion in Searchfield |
| TC-U1-006 | System/UI | US1 | Performance p95 Avg-capazity |
| TC-U1-007 | System/UI | US1 | Performance p95 Huge-capazity |
| TC-U8-001 | System/UI | US8 | Wildcard: Contains |
| TC-U8-002 | System/UI | US8 | Wildcard: NotContains |
| TC-U8-003 | System/UI | US8 | Wildcard: StartsWith |
| TC-U8-004 | System/UI | US8 | Wildcard: EndsWith |
| TC-U8-005 | System/UI | US8 | Wildcard: Empty |
| TC-U8-006 | System/UI | US8 | Wildcard Case-Insensitivity |
| TC-U8-007 | System/UI | US8 | Wildcard Escaping special characters |
| TC-U8-008 | System/UI | US8 | Wildcard auf numeric field |
| TC-U8-009 | System/UI | US8 | Wildcard Datefield |
| TC-U2-001 | API | US2 | Save personal Filter |
| TC-U2-002 | API | US2 | Save shared filter with permission |
| TC-U2-003 | API | US2 | Save shared filter without permission |
| TC-U2-004 | API | US2 | Save shared filter without groups |
| TC-U2-005 | API | US2 | Update Groups of shared filter |
| TC-U3-001 | System/UI | US3 | Fields are correctly set when selecting predef. filter |
| TC-U3-002 | System/UI | US3 | All filterfields with correct user rights are editable |
| TC-U4-001 | API | US4 | Update and Save filter (Owner) |
| TC-U4-002 | API | US4 | Save existing filter as new (without Update right) |
| TC-U4-003 | API | US4 | User without permission can not set filter to public |
| TC-U5-001 | System/UI | US5 | Save filter as, keeps all filterdata (cloning existing filter) |
| TC-U5-002 | System/UI | US5 | No Dataloss when saving filter with same name |
| TC-U6-001 | System/UI | US6 | Savebutton visible after filtering |
| TC-U6-002 | API | US6 | Save filter as public |
| TC-U6-003 | API | US6 | Save filter as public without permission |
| TC-U7-001 | API | US7 | Rename Filter (Owner) |
| TC-U7-002 | API | US7 | Delete Filter (Owner) |
| TC-U7-003 | API | US7 | Edit Gruppen (Admin) |
| TC-U7-004 | API | US7 | Edit without permission |
| TC-U8-010 | System/UI | US8 | Wildcard + Multi-Select combined |
| TC-U8-011 | System/UI | US8 | Wildcard on customfield |
| TC-U9-003 | System/UI | US9 | Wildcard contains |
| TC-U9-004 | System/UI | US9 | Wildcard contains (negative) |
| TC-NF-001 | API | SEC | Input Validation against SQLi/XSS |
| TC-NF-002 | API | SEC | delete Filter (Owner) |
| TC-NF-003 | API | PERF | N+1 Query-Check |
| TC-NF-004 | System/UI | ACC | Keyboard control dropdowns |
| TC-NF-005 | System/UI | COMP | Browser-compatability |
| TC-NF-006 | API | PERF | Performance (timebehaviour) |
| TC-NF-007 | API | SEC | Authorization Matrix |
| TC-NF-008 | API | REL | Concurrent Update |
| TC-NF-009 | DB | REL | referential integrity |
| TC-NF-010 | System/UI | I18N | localisation |
| TC-U8-012-Avg | API | US8 | Wildcard Contains API on Name (Avg) |
| TC-U8-012-Huge | API | US8 | Wildcard Contains API on Name (Huge) |
| TC-U8-013-Avg | API | US8 | Wildcard StartsWith API on Serial (Avg) |
| TC-U8-013-Huge | API | US8 | Wildcard StartsWith API on Serial (Huge) |
| TC-U8-014-Avg | API | US8 | Wildcard EndsWith API on Serial (Avg) |
| TC-U8-014-Huge | API | US8 | Wildcard EndsWith API on Serial (Huge) |
| TC-OR-01 | System/UI | Risk | Delete single search criteria |
| TC-OR-02 | System/UI | Risk | Reset all |
| TC-OR-03 | System/UI | Risk | Close search |
| TC-OR-04 | System/UI | Risk | Save without search criteria |
| TC-OR-05 | System/UI | Risk | Field combinations |
| TC-OR-06 | System/UI | Risk | Wildcard persisted |
| TC-OR-07 | System/UI | Risk | Multi delete |
| TC-OR-08 | System/UI | Risk | Same name filter differenziation |
| TC-OR-09 | System/UI | Risk | Autocomplete prevents injection |
| TC-OR-10 | System/UI | Risk | Settings-Page access rights |
| TC-OR-11 | System/UI | Risk | Visibility of filters on settings page |
| TC-P1-001 | API/Back | US-PERM | Create predef. filter only with create rights |
| TC-P2-002 | API/Back | US-PERM | Visibility of filters based on role |
| TC-P2-003 | API/Back | US-PERM | UI prevents access without rights |
| TS-S1-001 | API/Back | US-SCOPE | Filter right company scope |
| TS-S1-002 | API/Back | US-SCOPE | Filter only visible for assigned groups |
| TS-F1-001 | API/Back | US-FILTER | Access on predefined filter via URL |
| TC-F1-003 | API/Back | US-FILTER | Softdelete and references |
| TC-L1-001 | API/Back | US-LOGIC | Wildcard * on field 'model' |
| TC-L1-002 | API/Back | US-LOGIC | Wildcard Escaping Literal * |
| TC-L1-003 | API/Back | US-LOGIC | Wildcard Escaping: %, _, \ |
| TC-L1-004 | API/Back | US-LOGIC | Daterange |
| TC-L1-005 | API/Back | US-LOGIC | AND OR combinations |
| TC-SEC-001 | API/Back | US-SEC | SQL-Injection preventions |
And here are some measurements of the response times we gather with different size backups. (HW still the same as mentioned in an earlier comment) All measurements were taken from the VM on the asset page using the newly developed search
| Scenario | Nr of Results / page | Wait in ms | Receive in ms |
|---|---|---|---|
| Filtering 2000 Assets + 1001 Custom Fields | 10 | 118 | 1 |
| Filtering 2000 Assets + 1001 Custom Fields | 20 | 138 | 2 |
| Filtering 2000 Assets + 1001 Custom Fields | 30 | 162 | 4 |
| Filtering 2000 Assets + 1001 Custom Fields | 50 | 198 | 6 |
| Filtering 2000 Assets + 1001 Custom Fields | 100 | 327 | 8 |
| Filtering 2000 Assets + 1001 Custom Fields | 150 | 425 | 11 |
| Filtering 2000 Assets + 1001 Custom Fields | 200 | 539 | 12 |
| Filtering 2000 Assets + 1001 Custom Fields | 500 | 1220 | 32 |
| Filtering 5000 Assets | 10 | 121 | 0 |
| Filtering 5000 Assets | 20 | 126 | 1 |
| Filtering 5000 Assets | 30 | 131 | 1 |
| Filtering 5000 Assets | 50 | 167 | 2 |
| Filtering 5000 Assets | 100 | 233 | 3 |
| Filtering 5000 Assets | 150 | 310 | 8 |
| Filtering 5000 Assets | 200 | 393 | 5 |
| Filtering 5000 Assets | 500 | 892 | 10 |
| Filtering 25000 Assets | 10 | 186 | 1 |
| Filtering 25000 Assets | 20 | 187 | 1 |
| Filtering 25000 Assets | 30 | 204 | 1 |
| Filtering 25000 Assets | 50 | 241 | 2 |
| Filtering 25000 Assets | 100 | 311 | 3 |
| Filtering 25000 Assets | 150 | 382 | 8 |
| Filtering 25000 Assets | 200 | 450 | 5 |
| Filtering 25000 Assets | 500 | 949 | 10 |
| Filtering 50000 Assets | 10 | 175 | 0 |
| Filtering 50000 Assets | 20 | 202 | 1 |
| Filtering 50000 Assets | 30 | 209 | 1 |
| Filtering 50000 Assets | 50 | 240 | 2 |
| Filtering 50000 Assets | 100 | 320 | 3 |
| Filtering 50000 Assets | 150 | 387 | 8 |
| Filtering 50000 Assets | 200 | 477 | 5 |
| Filtering 50000 Assets | 500 | 962 | 10 |
| Delete current filter and reload via new Adv. Search Button | 10 | 182 | 1 |
| Delete current filter and reload via new Adv. Search Button | 20 | 193 | 1 |
| Delete current filter and reload via new Adv. Search Button | 30 | 207 | 1 |
| Delete current filter and reload via new Adv. Search Button | 50 | 245 | 2 |
| Delete current filter and reload via new Adv. Search Button | 100 | 319 | 3 |
| Delete current filter and reload via new Adv. Search Button | 150 | 397 | 8 |
| Delete current filter and reload via new Adv. Search Button | 200 | 471 | 5 |
| Delete current filter and reload via new Adv. Search Button | 500 | 479 | 10 |
| Selecting predefined filter with 80 filled custom fields | n.a. | 65 | 0 |
| Selecting predefined filter with 60 filled custom fields | n.a. | 57 | 0 |
| Selecting predefined filter with 30 filled custom fields | n.a. | 36 | 0 |
| Loading of 50 predefined filters in new Advanced Search | n.a. | 30 | |
| Loading of 70 predefined filters in new Advanced Search | n.a. | 32 | |
| Loading of 90 predefined filters in new Advanced Search | n.a. | 34 | |
| Loading AssetsPage with Filter open 52548 rows, 200 custom fields | 500 | 626 | 20 |
| Loading AssetsPage with Filter open 52548 rows, 350 custom fields | 500 | 1740 | 34 |