Option Query

Option queries are used to give the user a pre-selected set of something to increase usability in the solution. This is typically a relation field, but can also be a text field. Utilizing option queries can greatly enhance the speed in which the user can fill in information. You can see the pre-selected posts if you click on the little arrow next to the field in question. There are no pre-selections made as default. Option queries are made and edited in LISA under the property tab for the field in question in the setting “Option Query” - click on the “…” symbol on the side to open an edit window.

• Note that this functionality can't handle endless text fields
• Note that you cannot use brackets ([ and ]) in the option query code

Option queries have their own special code format that looks similar to SQL, but isn't like SQL. Therefore you cannot paste SQL-code into option queries. The easiest way to understand this is to think “graphically” in a LIME-solution - as if the user described to you what he wanted. Below is a number of examples ordered by increasing complexity. Principally this is true everywhere; [card type you want to show] WHERE [you start from your target - which naturally have to be the same card type as the one before the where command]… and then graphically walking through the solution to what ever criteria you want. Easy peasy!

The most basic idea of an option query is that you want to show all available options (which is not done by default). Simply write a criteria that all is fulfilled for all posts. The query below is read as “show me all cards of the type [coworker] where the ID on that card isn't zero” (which is true for all of them)

coworker WHERE coworker.idcoworker <> 0

When you want to show the alternatives that has a certain value chosen in a set field, such as all coworkers that have the option administrators chosen, you simply write as follows.

coworker WHERE coworker.position LIKE '2704001'

In a lot of cases one criteria is simply not enough. Luckily adding more is easy - simply separate them by AND or OR.

decision WHERE decision.client.idclient = activerecord.client AND decision.decisiontype.name = "Pensionspremier"

In some cases where you want to set relations (let's say unpicked errands and set them to a specific coworker) you want to show the ones without a relation. This is easily done by the code below:

errand WHERE errand.coworker = null

If you want to combine two sets of posts that have different criteria you have to “staple the two sets ontop of each other”. This is done by the “UNION” command.

person WHERE person.company.idcompany = activerecord.company
UNION
person WHERE person.case.idcase = activerecord.case

The examples above deal with critera from the sub tabs on the card in question. To make it a bit more tricky here we have related persons to itself via a middle object - thereby creating the possibility to show relations between different persons. What we want to do is show the available options on a history card. Let's start with the person card; it has two tabs; “customer” and “seller” - these corresponds to the fields “customer” and “seller” on the middle object. Now, what we want to do is first show all customers belonging to a certain seller. We start from the target… “show me all persons (customers) where the seller tab has persons (sellers) with the ID 1401 (for example)”. This translates to the code below, which can just be pasted into the option query on the history card. If you want the similar effect on customer history cards - that is; show all related sellers - you simply do the same type of thing for them and make a union.

persons WHERE persons(customer).seller([tab on customer card]).seller([field on the middle object]).idperson([ID on the seller person card])

In this case coworkers are members of teams. One coworker can be a member of multiple teams, hence the middle object teamrole. Every coworker has a default team (this is the relation field we want the option query on) and only teams that the active user are member of should be listed.

team WHERE team.teamrole.coworker.idcoworker = activeuser.idcoworker

teamrole is a tab on the team card and coworker is the field on the teamrole card. Attempt to describe the flow of logic:

(wanted object)WHERE(wanted object).(tab relation on wanted object).(field relation on middle object).id

Another example of using an middle object is with two step businessform setup. Where depending on a businessform a sub businessform should be selected. The use of a middle object is needed, because multiple sub businessforms can belong to multiple businessforms.

businessformdetail where businessformdetail.businessformmiddle.businessform.idbusinessform = activerecord.businessform.idbusinessform