108 lines
5.3 KiB
Plaintext
108 lines
5.3 KiB
Plaintext
SEARCH SPECS
|
||
|
||
|
||
|
||
CASES
|
||
|
||
SEARCH:NEW: - Search dictionary: Auto remove orphaned words
|
||
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1878
|
||
|
||
WORKORDER:PARTS:SEARCH:CR:DUPLICATE 3358: - Parts Search on Parts Grid
|
||
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3310
|
||
|
||
WORKORDER:PARTS:SEARCH:CR:DUPLICATE 3310: - Ability to ‘search’ for a part while in a WO or PM
|
||
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3358
|
||
|
||
UI:WORKORDER:CR: - Have a search box for clients instead of having to use the slider to find a client
|
||
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3376
|
||
|
||
SEARCH:UI:GENERAL: - Be able to search from anywhere in any screen
|
||
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3459
|
||
|
||
SEARCH:WORKORDER:PO:QUOTE:PM: - Workorder and other numbered items need to be searchable by their number
|
||
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3506
|
||
|
||
|
||
|
||
REQUIREMENTS
|
||
|
||
- USE-CASE: Central text search for any match. Can include tags. Can specify a type of object result desired.
|
||
|
||
- MINIMUM 2 character words only are searchable
|
||
- MAXIMUM 255 character words only are indexed (cut off at 255 if longer)
|
||
|
||
- ? USE-CASE: In-object text search for the typeandid that user is in, e.g. when in Client info form can search on that client.
|
||
- This is problematic because it seems to require searching for related objects but that's deprecated to priority 2
|
||
- Maybe more ideally is a search that can be something like "search all workorders FOR THIS CLIENT" or search all units "FOR THIS CLIENT"
|
||
- UPDATE: For the above this is really a feature specific to this object, not a general search issue so not part of search at all
|
||
|
||
- USE-CASE: Picklist / chooser Search for text of a specific type of object, e.g. find all Clients that contain "squirrel" to drive picklists everywhere
|
||
- USE-CASE: No snippet (excerpts) just name and type. I think for the initial release I'm *not* going to include snippets with result for several reasons:
|
||
- Performance: better to get an immediate result than to wait a while to get excerpts that
|
||
- Bandwidth: will trigger a lot of probably unneeded Bandwidth and chew up cycles on the db and server
|
||
- Can be added later based on feedback (i.e. a lot of bitching)
|
||
- For performance it would be something that runs *after* the search results are returned, either on demand (user clicks on excert button, or slowly fills in the list async)
|
||
|
||
- NAME: in search index include a bool indicating the word is actually part of the name or equivalent of the object, this will make name searches WAAAAYYY easier!!!
|
||
- in non named objects it's whatever the primary identifier is, i.e. workorder number for a workorder, partnumber for a part
|
||
- Maybe all objects should have a "name" column in db be it a workorder number or part number just for consistency
|
||
- RIGHTS: if a search is performed that is not NAME ONLY then the user role must have rights to read the full object even if the results are found in the name as this simplifies things greatly
|
||
- TAGS: Any search, anywhere, can include tags (internally it will post filter on tags after initial text search or if no text then will just search tags)
|
||
|
||
- ROLES: Needs to internally be able to filter by CANREAD property of role user is in (e.g. if no rights to read client no clients returned)
|
||
- INDEX VISIBLE ID NUMBERS MUST be searchable so ensure they get put into text search with the regular text.
|
||
- OBJECT TYPE criteria support (AyaType must be included in search index)
|
||
|
||
- CLIENT_NOT_SERVER_REQUIREMENT: PARENT / OPENABLE OBJECT: Objects that are searchable but not openable directly will be handled by the client
|
||
- Maybe this is a client concern, not a backend concern as pre-finding all the parents at the backend for the results is slower than
|
||
dynamically pulling it for one being opened from the client
|
||
- This is in the object, not in the searchkey as it would be inefficient
|
||
- Maybe need parent AyaType as an ENUM ATTRIBUTE in the AyaType table for easy traversal?
|
||
|
||
- CLEANUP: Generator able to cleanup index with no matching word (if possible), index with no matching typeandid
|
||
- CJK INDEX support: same as v7 but tied to Locale, not globally
|
||
- GROUP BY: group by objectype then objectid (then created date?)
|
||
- Coding: break this into separate discrete classes, the old v7 code is very monolithic and in-elegant
|
||
|
||
//TODO:
|
||
- INDEXES: play with it and see what works best
|
||
|
||
|
||
|
||
PROPOSED SCHEMA
|
||
asearchdictionary
|
||
- id (long)
|
||
- word (nvarchar 255) (indexed?)
|
||
|
||
asearchkey
|
||
- id (long)
|
||
- wordid (fk on asearchdictionary.id)
|
||
- objectid (long id of source object)
|
||
- objecttype (AyaType as int of source object)
|
||
|
||
|
||
|
||
|
||
|
||
REFERENCE INFO
|
||
|
||
V7 Code:
|
||
- Word breaker: AyaBizUtils -> Break starting at line 1976
|
||
- Insert into db: DBUtil.cs -> ProcessKeywords starting at line 423
|
||
- Usage: Client.cs line 2104
|
||
- SearchResultList.cs (whole class, also there is an "ri" version for some reason I forget)
|
||
- V7 DB Schema:
|
||
|
||
CREATE TABLE [dbo].[ASEARCHDICTIONARY](
|
||
[AID] [uniqueidentifier] NOT NULL,
|
||
[AWORD] [nvarchar](255) NOT NULL
|
||
) ON [PRIMARY]
|
||
|
||
|
||
CREATE TABLE [dbo].[ASEARCHKEY](
|
||
[AWORDID] [uniqueidentifier] NOT NULL,
|
||
[ASOURCEOBJECTID] [uniqueidentifier] NOT NULL,
|
||
[ASOURCEOBJECTTYPE] [smallint] NOT NULL
|
||
) ON [PRIMARY]
|
||
|