Skip navigation

FootPrints service desk

2 Posts authored by: Toby Draper Employee
Share:|

When you configure email settings in Footprints Service Core, there will be certain addresses you will want to ignore from the mailbox receiving the message or there may be email addresses you will accept incoming email from but will not want to send notifications to. An example scenario is where you accept email notifications from another Service Management application to log tickets in Footprints but do not want to send notifications back to that mailbox as it is an automated function and you risk creating a loop.

 

So these can be set at the top level for system wide filters in Administration > System > Email (scroll to the bottom of the page to see the system wide settings);

 

system filter.JPG.jpg

You can specify additional rules, not set at System level for individual Workspaces in situations where you wish to accept or send from one project but not another. For the Workspace you wish to apply additional filters to, go to Administration > Workspace > Mail Preferences and again find the filter configuration at the bottom of the page;

 

workspace filters.JPG.jpg

Footprints has a function to add addresses to the SPAM list (even if the SPAM catcher is disabled) if 5 emails from a specific address within the last 15 emails received from that address have the same first 50 characters in the subject line.  There is an entry you can add to the MRLocalDefs file that will allow specific email addresses from being added to the list.

 

Depending on how granular you want to be with allowing emails to get through the SPAM filter you have 3 options, all involve adding a variable to the MRlocalDefs file.

 

  1. The footprints\cgi\MRlocalDefs file needs to be edited. Make a backup copy of this file.
  2. Now open the MRlocalDefs file in a text editor such as notepad or WordPad.
  3. Insert the following variable(s) on a line by itself to prevent emails from being blocked as Spam:


     You can use :


     @THIS_EMAIL_IS_NEVER_SPAM_REGEX_ARRAY = ''; # two single quotes


... to disable all spam checking, however, it's safer to use -


     @THIS_EMAIL_IS_NEVER_SPAM_REGEX_ARRAY = ('domain.com');


... to designate a domain or address to always allow.

    

     $THIS_EMAIL_IS_NEVER_SPAM = 'username@domain.com';


... to designate a single user address to always allow.


     $THIS_EMAIL_IS_NEVER_SPAM_ARRAY = ('username@domain.com', 'anotheruser@domain.com');


... to designate a multiple user addresses to always allow.



    

      4. Ensure this line is above the current last line of the file which currently has a "1;"

        

          ... and should be below the line that has:

 

                    ### Location of footprints root directory ##################################

Share:|

I have spent a few days trying to gauge what conversations are taking place in Customer Support for the Footprints Service Core product. I detected a discernible trend with queries and issues around the Form Designer so I thought I would try and identify some hints and tips, general things to look out for and be aware of.

 

Contact Information

The Contact Information form is pulled through to Form Designer from the Address Book configuration, where the fields are managed in "Field Maintenance" - akin to how fields were managed in versions previous to Footprints Service Core 11.

While you may hold various bits and pieces of information on a customer as a contact in your Address Book, you may not wish the Agent to view or amend that information while they are logging a new issue. Contact information fields can be omitted easily in Form Designer using a "light switch" which sends them to a holding area of available fields to the right.


lightswitch.JPG.jpg


Hovering over the top right of a field in the Contact Information tab, we can edit the field with the pencil icon and “flick the switch” to move the field to the list on the right



This feature allows you to quickly remove Address Book fields from the form or to quickly edit them out from the Contact Information tab to be dragged to a custom tab you have created to contain that information.


 

Under The Hood

When Form Designer is accessed by a Workspace Administrator, a file named FBDesignData.json is created in the Workspace's directory;

 

:\Footprints Service Core\db\MASTERn\MR (where the n in MASTERn is the Workspace number)

 

Changes to the draft form are written to that file until the admin clicks Publish Form, at which point the changes are written to the FBLayout table on the database and to the Schema file, also held in the above location. The FBDesignData.json file is then deleted.

If you wish to check which fields appear on your form or to troubleshoot the form, the Schema file is a good place to start. For example, in the screenshot below, you can see that the issue form once had a field named "Error Message", which has subsequently been deleted.


schema.JPG.jpg


 

Deleted Fields

Click the dustbin (trash can)  icon to delete a field and you will encounter the following dialogue box;


delete field.JPG.jpg



Essentially, the table which contains your issue records in this Workspace in the database will have the column corresponding to this field deleted. So that is all the data you captured in this field for every issue logged in the Workspace. It may be advisable to hide the field, rather than delete it. This way, the data remains intact in the database and the field can be easily reinstated to the form if required.


hide.JPG.jpg


My “Symptom” field was going to be deleted but, as a precaution, I decided to mark it hidden. Management may decide to reinstate that field or report on the data at some point in the future.

Filter Blog

By date:
By tag: