We had an incident where a user indexed an item to 400* where when coupled with auto foldering created a small mess. We have the mess cleaned up but I want to force the users to enter the entire keyword "SS00AA000000", but be able to retrieve using wild characters like 400* without having to put a wild character in every character space.
We currently have a mask that is built like this: SS99AA999999. I put the 9's in the mask to allow * when retrieving.
Can you guide me how I can force the users to enter the entire keyword value when indexing or re-indexing, but allow them to retrieve by just entering in a couple of characters?
It seems that if I check the Full Field Entry Required box in Keyword Type configuration it will not allow a user to retrieve by entering 400*.
I see this as a common question related to masking. By nature of how the keyword fields are configured the indexing panel will be the same as the standard retrieval panel. Most of the time a choice has to be made about what is more important - Indexing or Retrieval. The usual advice is to remove the masking and find an easier way for users to get the correct keyword (OCR, Barcodes, External Datasets, etc).
However, I think you can get the best of both worlds based on what you have described.
First, to get the data integrity for this keyword, I would set the mask as if I was only ever doing indexing. When it comes to database design, garbage in = garbage out (as you found with the unexpected folders).
Next, instead of the standard retrieval, have the users use the foldering interface for retrieval. You will need to use the CSE Case Number as a Folder Name in the child folders (I get the feeling this is already set in your system) and use the display children popup option to turn it into a text search of folder names. I built this in my demo system so here are the key points:
Use the CSE Case Number in the Folder Name-
Next, in the parent folder to the Case Folders, set the display to use pop ups for children with as many characters as you need-
I think this will work for any client (foldering is usually awesome about compatability!)
Thick Client-
Unity Client-
At this point without knowing your solution better here is all I can think of...
That issue comes down to folder design (database design - 1 to many relationships - many to many relationships)- Consider what unifies those mulitivalue cases. Is it a Person ID (unique identifier)? Because Dynamic folders are really just Custom Queries to the OnBase database I think it would be easy to build both structures into a User Friendly interface. Consider the following structure:
- Search By Person
- Person ID - Last Name
- Case Number (Parent: link to Person Record by Person ID)
- Search By Case
- Case Number
These could be added to the existing file cabnet or created as their own stand alone cabnets/folders.
These may look like Duplicate Folders, but they are actually more like Views in a Database, simply pointing to the same unique record but displaying it differently. If you are using any static documents in your solution then consider using Related Folders as outlined in the Folders MRG.
There are 2 tools I use with foldering that let me rapidly test these designs in a test system.
First, to delete existing folders I use the right click option in Configuration- This only deletes the folders in the client (not the configuration)
Then I can recreate the folders using the Autofolder Option under Doc Type Config(plus this is a great test to see if my current autofolder [+auto create child] config is working). This tool is nice because I can limit the creation to 5 (or any number I want) folders being created in the case I want to make changes without having to wait on all the folders to be created only to have to wait to delete all of them.
