View XML

View XML

All records in Brick River tables are defined by sets of XML elements that our data engine processes when interacting with database tables. 

XML elements stored in multiple Views may contribute to the Final XML that is ultimately passed through our data engine.

This article dives in to the weeds to thoroughly explain the relationship between:

  • System Views - the built in 'View Bases' that define Brick River core Content and Contact records
  • Bundle Views - built in 'specialty View Bases' that can be added to Brick River to extend the XML stored in System Views, and
  • Custom Views - the Views that you create to add to and extend the XML stored in System and Bundle Views .

System Views, Bundle Views and View Base XML

Out of the box, Brick River includes 8 visible and 2 hidden System Views that provide baseline definitions for basic types of Content and Contacts.

Visible on  Web Console menus are:

  • Content -  Blog Posts, Events, Features, News
  • Contacts - Authors, People, Email Registrants, All Contacts (All Contacts is only  visible to Administrator users)
  • Hidden Contacts Views - Organizations and Registrants, are hidden by default and do not appear on the Contacts Menu.
  • One additional hidden View - Active - defines records in the Communications table. 

For some sites, customers may use Brick River Bundle Views - which are Views that enhance System Views for specific purposes.

For example, our developers worked on so many websites for nonprofit organizations - it made sense to create a 'Nonprofits' Bundle - to define Contacts such as  Volunteers and Donors - and to define Content such as Fundraisers and Work Projects.

System and Bundle Views create the View Base XML - the 'base set' of XML elements that define a basic Type of Content or Contact.

The View Base XML can be reviewed and copied to the clipboard using the View Base button in the View Editor window.

The View Base XML can not be directly edited.  Developers must extend the View Base XML by composing XML Overlays in Custom Views.

With nothing in place to customize the View Base XML - the View Base is the Final XML for a given View.

Custom Views Types, XML Overlays, and View Permissions

There are three types of Custom Views - Custom Root Views, Group Views and User Views.  The Type is set in the View Editor using the field: 'Who does this view apply to?'
1 Custom Root Views - Apply to 'Everyone' - they do not change any permissions for Users or Groups.  A Custom Root View uses an XML Overlay with elements and attributes that can extend and overwrite matched elements in the View Base.
2 Group Views and User Views - Apply to 'Only specific users or groups' that alter permissions to access View Records or specific fields on records.  They can also include XML Overlays which alter the View Base XML.
Select 'Only specific users and groups' to enable controls for linking Users and / or Groups for the View.
The above settings determine that DemoView is a Group View that will only be visible and accessible to system Users are members of the News Creator Group.  The XML Overlay contains the minimal required information - the <View> tag with the Id and TableId attributes.  This overlay makes no changes to View Base XML.

The order of influence of View Customization is:
USER Views - customize GROUP Views - customize CUSTOM ROOT Views - customize VIEW BASE - to create FINAL XML.

In the article, Contacts, Content, and Views we saw that the Organization View was not present on the Content menu because it had View Base XML containing the attribute -  Invisible="true"

<Table Id="Contacts" Name="Organizations" Invisible="true">

A Custom View was created with an XML Overlay which included Invisible="false

<View Id="Organizations" Invisible="false">

The Final XML interpreted by the data engine used the content of the XML Overlay to overwrite and add to the elements and attributes of the View Base XML

<Table Id="Contacts"> 
 <View Id="Organizations" Invisible="false">

Multiple Custom Views and Permissions Management

A  more complex example demonstrates how multiple Custom Views manage User and Groups permissions in Custom Views.

Consider a site that organizes the activity of thousands of volunteers.

There are five summer interns who call volunteers to match them to volunteer opportunities in their town.  Volunteers should not be scheduled for activities until they have passed a background check.

Two interns have additional jobs.  Hakeem registers new volunteers and submits paperwork for their background check.  Abigail files the paperwork when it is received and authorizes new volunteers as "Passed" (or "Failed" - but all the volunteers in our example will pass).

All interns use a Custom View called Volunteers to lookup contact information and update Volunteer data.

First -

Create a permissions GROUP called Interns that includes all five summer interns:

Next -

Create a Custom Root View called Volunteers that defines a Contact type of Volunteer.  This View would use an XML Overlay to define fields unique to Volunteers - including the field: "Background Check". 
Hakeem will set this field to "Pending" when registering new volunteers  and Abigail will set it to  "Passed" after filing the completed paperwork.

Next -

Create a Group View for the Interns Group which customizes the Volunteers View.  Apply a filter to only display volunteers where the Background Check  field is PASSED. This will prevent the interns from calling to schedule volunteers who have not yet cleared the background check.

Next -

create a User View for Hakeem and Abigail that Customizes Volunteers to display all volunteers regardless of the background check status.

Hakeem and Abigail are in the Interns Group - but the permission for the USER view will customize the GROUP view - allowing Hakeem and Abigail to see all volunteers while other interns who log in will be restricted to the filter defined for the Interns GROUP View.

Schedule a demo and see how easy it can be

Give us 15 minutes to hear your situation and share our solution.

Schedule a demo