Would be to build 10 relationships R1 to R10 and set CF = PatternCount(list (R1::ticketID) & ... & list(R10::ticketID); ticketID)
You're making this overly complicated …
If you flag your problems EDIT: tickets as solved, you can add as a relationship predicate and remove the portal filter on matchcount EDIT: for the Ticket_self relationship.
Well actually the situation is a bit more complicated. What you mark as solved is the ticket, not the problems. The problems are a client's perceived list of concerns which might - or not - meet the real situation.
Example: a lot of data is on a shared volume. Client says "I can't print scanned documents", "I can't import images". The solution is : mount the shared partition, which has somehow been dismounted. Ticket solved.
Note the edits on my original post; I meant "tickets solved" since I was referring to the Ticket_self relationship and the portal filter which then would be unnecessary.
If you want, it's something like an expert system: patient says
- got headache
- lack of appetite
- can't concentrate
and you come up with the most probable diagnostics, ordered by probability of being the right diagnosis, based upon past ones.
While this is truly fascinating – and this forum could use such a system – what you wanted was an efficient method to see a list of solved tickets, sorted by their count of 'problems' matching the problems of the current ticket.
Got any other (perceived) problems? Shall we open a new ticket?
Parsing it down, you will have created a table (library) of solved symptoms. Each would have a ID , an agreed name, and field containing "keywords". And of course the actual solution. As opposed to solved tickets.
Much like one would have a table of components for a mechanical assembly or tasks for a flat rate repair system.