IntelliSense, improved help and new script editor

AMODIT version 2.9 introduces significantly improved rules editor. The main changes are:

• improved layout of rule editing window
• new script editor with syntax highlighting and automatic code formatting
• IntelliSense, which shows the function names and the field names while typing
• help that dynamically shows content based on the context

Rule editing window

This is how the window looked like before upgrade:

And this is how it looks like in new version:

It is worth noting that this window now occupies the entire screen available, so there is more space for entering information. In addition, options have been better grouped and are easier to understand. The window is graphically divided into two parts. Upper defines when the rule is started, and the bottom determines what is to happen if the rule fires. In addition, there is more space to display the script code.

Script editor

When you click on the code then script editor will show up. In this view, the left side of the screen allows you to edit the script and the right displays context-sensitive help.

To view a description of a function in the contextual help, you can do any of four actions:

• Select it from the drop-down list in the upper right corner, or ...
• Search using a search box in the upper right corner, or ...
• Move curson to the function in your code using the mouse or keyboard, or ...
• Start typing the name of it in the editor! This last option is IntelliSense.

IntelliSense

If you type the beginning of the function name, the IntelliSense shows matching names, and if you select the right one it will show a brief description, the short description and a list of parameters. In addition, help in the right part of the screen displays the function description of examples of use.

The suggested names are also keywords, form fields and system fields. The editor highlights the syntax and automatically formats the code. They are also buttons for formatting and inserting fields.

We hope that these changes will greatly facilitate defining rules. If you have any comments or sugestionspPlease leave tchem below.

Be careful when using dates in rules

When you write rules in AMODIT you need to be careful when using dates. AMODIT supports multiple languages and it influences how dates are shown and interpreted. In US English date format is mm/dd/yyyy but for example in Polish it is yyyy-mm-dd. Therefore it is risky to write:
[DateTo]>="5/2/2014"

It is better to write:
[DateTo]>=DateTime(2014,5,2)

This way you can avoid problems when user switches to another language.

AddUserToRole - new function

New function have been added to help control permissions more precisely. This function can change user's role. Therefore now you can use rules to give or reject permissions. For example if you want to take away someone's permissions you can add user to role "forbidden".

Roles:

• cc - keep informed by email + read-only rights
• contributor - keep informed by email + read-write rights
• reader - read-only rights, without notifications
• forbidden - no access

Note: After you change users role it is stored in database.

New function: FillFieldsFromString

This function is very useful when you want to store many parts of information ia a string and then save it to proper fields. It makes it easy to have tricky effect. Lets say you have a list of customers. Every customer is described with fields like "name","street","city" and "numer of employees". So you can set it up in AMODIT as an external dictionary. But dictionaries have just two fields; "name" and "description". But you can store "street","city" and "numer of employees" in dictionatry item's "description" using separator, f.e. "Hollywood Blvd|Los Angeles|3500". Using new function your can easily read such a string and save pieces of information into proper fields.

Another example is a scenario when you have your customers in external database. You want to query it for additional data every time user types-in customer number and store it in proper fields on a form. You can do it with an example code below:

cs="DSN=BAZA;UID=user;PWD=pa$$";
sql="select SYS_DAO.f_get_Customer([CUST_ID]) from DUAL";
res=ExecuteSQL(cs,sql);
FillFieldsFromString(res,"##","Client name","Client name","Tax number","Registry number","Client address"," Client address "," Client address "," Client address ");

This rule retrieve customer data from database in the form of string with values separated by ## string. Ex:
ASTRAFOX##sp. z o.o.##5252171560##13928533##UL. TABOROWA##8##02-699##WARSZAWA

FillFieldsFromString function splits retrieved string and puts values into given fields. You can add as many fields names as you wish (input string can contain any number of values separated by given separator). If you want to omit specified position you can pass empty field name "". If one field is specified more than once, then values from specific positions are concatenated into this field.

Formatting rules

In new version there is a new buton in rules editing window. It is simply called "Format" and clicking it results in "nice" reformatting of a rule. See example below:

And after clicking the button rule gets reformatted:

It is especially visible in part with {}.
Simple and useful :)

AddTableRow & RemoveTableRow

We have added 2 new functions to use in rules:

 

AddTableRow("table")

Adds row to a given table. Returns index of added row (index can be used in Set function to fill data)

Function arguments:

• table - names of table field.

 

RemoveTableRow("table",(first|last|row number))

Remove given row fromo a given table.

Function arguments:

• table - names of table field.
• (first|last|row number) - which row.

ShowSection() and HideSection()

Two new functions have been introduced to rules engine. They allow hiding and showing sections of a web form depending on certain conditions, f.e. value of other fields of a form and stage of a process.

So now there is a full set of such functions:
ShowSection(sectionName)
HideSection(sectionName)
ShowField(fieldName)
HideField(fieldName)

AMODIT 1.9

There is new version of AMODIT available. There is one important new feature in this version: modification locking. This feature forbids editing same case by two persons simultaneously. It can be helpful if there are many users working on group of cases. When this feature is turned on, then opening a case by one user for editing will lock a case, so other users will be able to open this case just in read-only mode. They will be able to see who is editing the case at the moment.
Case will be unlocked when user exits from case. Additionally lock will expire after 30 minutes (or other time set in settings).

To turn this feature on you need to go to "System settings":

There is also one minor new feature in this version of AMODIT. It is ConditionalGet function. It gets values from one column of a table from selected rows. It has following syntax:

ConditionalGet ( "table (>table>table...)", "Field/column name", "Conditional field name", "Operator =, ==, !=, <>, <, >, <=, >=", "Conditional value/field name", "Separator" )

For example...

ConditionalGet(„People”,”email”,”city”,”==”,”London”,”;„);

... will get values from column "email" from table "People" from rows where "city" is equal to "London" and will separate these values with semicolon. 

Hiding form fields "on the fly"

Sometimes it would be nice to show or hide a field depending on some conditions. For example depending on value of other field. Typical situation is when you have a drop down list with various choices but last one is "Other". When user chooses this option it is nice to show a field to let her/him type what "Other" really is.

And a good news is that from version 1.8.5 you will have such option. There two new functions:
HideField("fieldname")
and
ShowField("fieldname")


So you can use automatic rule to show or hide fields.

Note: To make it work well automatic rules are now also fired just before showing a form.

Sending emails from case and receiving responses

AMODIT gives you ability to send email from case using rules.
There are two functions which allow it.

SendMessage ( "userLogin" | "login@address.com", "Subject", "Text" [, "from@address.com"] )
,which sends simple email and
SendCasePrintMail ( "userLogin" | "login@address.com", "Subject", "Text", headers?, signatures?, attachments?, history? [, "Chosen Section", "from@address.com"] )
which can send email with form, attachments, signatures and history.

Important thing is that you can reply to such an email and AMODIT will receive it and store as a new comment into proper case. To achieve it AMODIT stores case ID in email header.

There is one more interesting thing. You can check who have sent the response. There are special fields that can be read in rules:

• [CaseLastMailFrom] - sender of a last email (full name and address, like John Smith <john.smith@abc.com>)
• [CaseLastMailFromAddress] - sender of a last email (address only, like john.smith@abc.com )
• [LastMailFromTitle] - title of last email response received

All these features give you possibility to support sending and receiving emails inside AMODIT system and associate them with cases.

Signing, forwarding, form validating etc.

There are some small changes we have introduced in AMODIT 1.6.8 (which will be perhaps 1.7 stable version) in area of signing and forwarding.
The point is you sometimes want to make some manual rules to accept or reject using just one click. Rejecting is simple but when you want to accept from rule there are several options. You may want to sign one field on a form and then change stage of case. Problem is that you may want to have some required fields.
So if you put simply:

SignField("FieldName","Some comment");
ForwardCase("Someone","New stage");

If there are some required fields empty then you will get signature but forwaring will fail (and show proper explanation to a user). So this is not something you would like.

So there are two new changes:
1. Function IsFormValid() which returns if all required fields are filled-in. So you can write:

if (IsFormValid()) { SignField("FieldName","Some comment"); }

2. You can choose to define rules by just clicking checkbox "Sign case after successful rule evaluation" and choose a field (till now it was possible to sign whole case only).

Error tolerant programming

One of principles of AMODIT is to make it as easy as possible. You can start using workflow in a few minutes and end users can propose new procedure giving it just a name and names of possible stages.
However, later some procedures get more mature and stable and we want to add some automation. This is why AMODIT is equipped with rules engine and special scripting language. Syntax is similar to C#, but is simplified. For example there are no loops, not to let user a chance to make infinite loop.

For those who are familiar with C# it is known that you have to put semicolon ";" after every statement.
For example:
a = a + 1;
b = a * 2;

But we assume that AMODIT users don't have to be experienced programmers and they can forget about semicolons. So compiler is trying to guess if there should be a semicolor and put it there itself. Thus previous example can be simply writtten as:

a = a + 1
b = a * 2

Another thing that is made simple is referring to form fields. Generally if you want to refer to a field you use its name in square brackets:

[field1] = [fields2] + 1;

However, there are some functions which perform special actions with fields. For example SignField(field,comment) function puts a signature into a sign field. First parameter is a name of a field (not its value) so you have to put is as a string:

SignField("field1","my comment");

But users very often make mistakes writing:

SignField([field1],"my comment") 

or

SignField("[field1]","my comment") 

From syntax point of view it is error. But it is common error and we decided to make compiler smarter.
So now you can use all combinations:

1. SignField("field1","my comment");
2. SignField([field1],"my comment") 
3. SignField("[field1]","my comment") 

Just the first one is really valid, but all others are tollerated because compiler can clearly recognize user's intention. And this is what I call "error tolerant programming"!

Collecting signatures and next step

Functionality of collecting signatures was present for some time already. But now it is extended with possibility to define what will happen if the whole process with finish with acceptance of rejection.
So from now on you can not only define who should sign the case (or part of it) and ask them one by one or at the same time.

So now you can define processes of collecting signatures and define who will take care of it after signatures are collected. You can also define more sofisticated scenarios if you use rules, because you can define automatic rule which will fire on certain stage. So you have lots of options :)