Friday, June 24, 2011

Using Postcodes in BlueBox2.0 via PostCodeAnywhere

Recently we have integrated an excellent UK postcodes library/database/service with BlueBox2.0. This is the PostCodeAnywhere product. The API's have been integrated formally into BlueBox2.0 and offer the following features:
  • Postcode Lookup
  • Find nearest-to from a certain address (used for finding 'a store near you' etc)
  • Geo-spatial data (long/lat data for mapping)
  • Government Data (wards/districts etc)
  • Database Cleansing
Installing PostCode Lookups into BlueBox2.0

This is a very easy process. Simply go to toe Postcode Module under Integration. There you will be asked for your PostcodeAnywhere customer 'code' and the API Key for your lookup-account with them. These are easily got by surfing to PostcodeAnywhere.co.uk using this link:

Postcode Anywhere

Sign up for an account, then create a new key from the backoffice menu. Once you have your account and key simply enter these into the PostCode module by clicking on Accounts in the top menu. Click on 'DataFunctions->Add' and fill in your account details.

Once these have been filled in and the account is added, go back to the Postcodes Dashboard and you will see a test lookup facility which you can use to test if the account is working correctly.

Configuring your BlueBox2.0 System for Postcode Use

Now that Postcodes have been set up in your system, you may want to configure it as follows:

Limiting abuse: BB2.0 has a default limit of 3 lookups per IP address per hour, to stop web-users from chewing up your credits unnecessarily. This would apply for 'public use', but if you have a backoffice function you may want to set this to a much higher amount, or remove the limit altogether. There is a bbsetting for this, called bbsetting_postcode_limit_per_hour. If you set this to 0, there will be no limit.

Forcing Postcode Lookups: The postcode module will not automatically 'hijack' fields with the name containing 'zipcode', but if you want all 'zipcode' formfields to automatically become postcode lookups, you can set bbsetting_postcode_force_lookups_in_forms to 1.

Disabiling Postal Address fields for manual entry: Part of postcode lookup functionality is to stop users from messing up the data. To make your address fields 'readonly' use bbsetting_readonly_fields for each module that has postal address fields. Ie for the user table you will set bb_users->bbsetting_readonly_fields to be:

postal_address,
postal_address2,
postal_suburb,
postal_city,
postal_state,

Saturday, June 18, 2011

bbsetting_item_data_qty_blank_in_forms

A new bbsetting for BB2.0 is bb_item_data->bbsetting_item_data_qty_blank_in_forms which sets the qty field in financial docs to 'blank' as opposed to zero or 1. It is part of the bb_item_data class. To edit this setting go to admin>module settings and select bb_item_data from the class list. Then select this bbsetting from the list.

Friday, June 17, 2011

PHP secure communications library

This week one of our BlueBox team discovered a nifty PHP secure communications library which we needed for SFTP comms between one of our Linux Servers and a Windows machine. It works great and helped us avoid adding extra libraries to our server to achieve the same thing.

Also this week, as part of the axe sharpening process we started the redevelopment of our corporate website at www.blueboxonline.com. It has been a long time coming, and what we decided to do was get the design done by a 3rd party (we are too close to the machine to do it ourselves).

Our aim is to keep the site clean and simple, and above all to have a scalable, neat CSS structure behind it to ensure that as we expand the content areas, that the site remains navigable and easy to use.

Friday, June 10, 2011

Easy extension of User Data

This week I faced the challenge of adding more data to the standard BB2.0 system user profile than is normally required.

One way it to use the list of generic xtra_fields, but this can be limiting.

In writing a system for Care Management, the user data that needs to be stored is very detailed and complex. It does not make sense to extend the 'standard user table' with all these extra fields.

So I developed a cool 'extension' function that essentially copies the required fields to the matching user record in the main user table, while allowing you the autonomy of building a bespoke module that meets your needs.

So, for example, if I wanted to create a new module to store info regarding tradespeople in a new module called bb_tradespeople, you would create the new module, and have a link-field called userISbb_usersID in the table. You would also include all the 'common' fields in your new table, for example : first_name, last_name, email, and telephone. (These need to be named exactly as they are in the bb_users table).

Now that your new class has been created, extend it using the 3 over-ride methods below:

 function pre_edit_form($conf=NULL) {   
                global $global, $class, $method;  
                $res=load_linked_user_data_in_external_module($conf,"userISbb_usersID");  
                $conf=$res;  
                return $conf;  
           }  
function post_add($conf=NULL) {   
                global $global, $class, $method;  
                $res=process_linked_user_data_in_external_module($conf,"userISbb_usersID",array("Debtors"));  
                $conf=$res;  
                return $conf;  
           }  
function post_edit($conf=NULL) {   
                global $global, $class, $method;  
                $res=process_linked_user_data_in_external_module($conf,"userISbb_usersID",array("Debtors"));  
                $conf=$res;  
                return $conf;  
}  

The 2 new functions are

load_linked_user_data_in_external_module


this takes the standard $conf input as well as a string with the field name which links to the user table

and

process_linked_user_data_in_external_module

this takes the standard $conf input as well as a string with the field name which links to the user table and also the group that you want to add the new linked-user into.

Thursday, June 2, 2011

BB2.0 Imports : Adding linked data on-the-fly

For a while now I have wanted to be able to add data to other tables via the standard BB2.0 CSV import functionality.

For example, if I am importing staff data, it would be great if I could import the user linked to the staff data at the same time, rather than having to import the user first and then import the staff data separately.

This has led to the addition of a nifty noew import syntax for bb2.0 imports, namely add_linked_data_ which allows you to add extra columns to your CSV import spreadsheet which look like this:

add_linked_data_userISbb_usersID.first_name or 
add_linked_data_userISbb_usersID.last_name

The presence of these columns will force the import script to check to see if a field exists in this import called

userISbb_usersID

and if so, to try to add the new data found in these columns to the database BEFORE importing the current line of data, and thereafter linking the field  userISbb_usersID to the newly added data. If it finds that the data already exists (it may have been added a few lines previously for another row in the import) then it simply links this row's data to the existing entry.