Added #17494: Advanced-search and predefined filters

[cz-lucas]

Added #17494: Advanced-search and predefined filters

New functionality

Advanced search:

• Added new advanced-search which allows filtering on backend
• Added functionality to manage private and public filters. The provided new permissions for new functionality
• Create new settings-page to manage filters

API:

• Added API to manage the predefined filters

Database:

• Added tables for predefined filters and predefined filter permissions

Testing:

• Added plenty of unit- and feature tests for the advanced search and predefined filters
• Added tests for the "old" advanced search

Screenshots

Advanced search:

Predefined filter create modal:

Predefined filter settings page

[JonasGoseberg]

Hi there,

we have made the necessary changes you mentioned earlier.

Summary:

• reverted the formatting stuff
• removed files related to our development environment
• removed all build assets we did not use
• removed Translations except en-US
• removed .gitignore
• moved notifications to a separate PR (Added #18289: Livewire notifications #18290)
• Provided technical details (Added #17494: Advanced-search and predefined filters #18264 (comment))

[JonasGoseberg]

Predefined Filter Feature

In addition to the previous explanation, this section covers the new predefined filter functionality.

Summary
This part adds a feature to save the current filter configuration, allowing users to quickly reapply it later.

Database Structure

We added two new tables:

1. predefined_filters

This table stores each predefined filter and its associated metadata.

Field	Type	Null	Key	Default	Extra	Explanation
id	bigint(20) unsigned	NO	PRI	NULL	auto_increment	Primary key
name	varchar(191)	NO		NULL		Name of the filter
created_by	int(10) unsigned	NO		NULL		Creator user ID
created_at	timestamp	YES		current_timestamp()		Creation time
updated_at	timestamp	YES		current_timestamp()	on update current_timestamp()	Last update time
deleted_at	timestamp	YES		NULL		Soft delete time
filter_data	longtext	NO		NULL		Actual filter data (JSON)
is_public	tinyint(1)	NO		0		Whether the filter is public
object_type	varchar(191)	YES		asset		Defaults to asset (placeholder for future use)

Filter Examples

Standard fields (e.g. company, asset_tag)

[
  {
    "field": "company",
    "value": [8, "com"],
    "operator": "contains",
    "logic": "AND"
  }
]

Explanation:

• 8 → exact company ID
• "com" → substring used in the contains search

Custom fields

[
  {
    "field": "_snipeit_ram_3",
    "value": "32",
    "operator": "equals",
    "logic": "AND"
  }
]

Explanation:

• Custom fields use the same structure as standard fields
• Prefix snipeit_ follows the pattern in the assets table

Checked-out-to (assigned_to)

[
  {
    "field": "assigned_to",
    "value": {
      "type": "App\\Models\\Asset",
      "value": "Demo"
    },
    "operator": "equals",
    "logic": "AND"
  }
]

Explanation:

• Handles relationships to other objects (e.g., assets or users)
• "type" specifies the related model
• "value" specifies the related entity

Date range filters

[
  {
    "field": "purchase_date",
    "value": {
      "startDate": "2024-03-14",
      "endDate": "2025-12-14"
    },
    "operator": "equals",
    "logic": "AND"
  }
]

Explanation:

• Supports filtering by date ranges
• "startDate" and "endDate" define the range

2. predefined_filter_permissions

The predefined_filter_permissions table is a many-to-many mapping between predefined filters and permission groups. It defines which groups have access to which filters.

Field	Type	Null	Key	Default	Extra	Explanation
id	bigint(20) unsigned	NO	PRI	NULL	auto_increment	Primary key
predefined_filter_id	bigint(20) unsigned	NO	MUL	NULL		Linked predefined filter ID
permission_group_id	bigint(20) unsigned	NO		NULL		Linked permission group ID
created_by	int(10) unsigned	NO		NULL		Creator user ID
created_at	timestamp	YES		NULL		Creation time
updated_at	timestamp	YES		NULL		Last update time

Permission System

We added four new permissions for predefined filters:

• create
• view
• edit
• delete

How it works:

• A user can perform an action on a predefined filter if they belong to a permission group linked to that filter and the group has the corresponding permission.
• Superusers bypass all restrictions and can perform any action.

[marcusmoore]

Thank you for addressing the changes requested (I know it was a lot). This is a big PR (understandably) so our team is going to need some time to review and consider it.