Edit Your Application

Wednesday, April 18, 2007 11:13 AM by nairdo

If we could, we would prefer to lock down the Member Status field so that only our small Evangelism admin team could edit it.  Unfortunately Arena does not allow this particular field to be locked in this way (most other Arena areas and fields can).

Since Arena is built on top of its own CMS foundation, you have the ability to edit any "screen" (ie page).   Fortunately we were able to at least remind everyone what they were told in training by adding an HTML block to that page where the Member Status is updated.  For us it now looks like this (see the yellow note box I added):

 Our Arena edit family screen

This is done simply by finding the Edit Family Wizard page and inserting a new HTML control above the existing Family Wizard control as I've done here:

Then back on the Edit Family Wizard page, since I've given myself rights to edit that control, I just update the HTML with the nice WYSIWYG editor and add my fancy yellow text box.

There aren't too many applications that I'm aware of that let you edit them like this. 

Comments

  1. Derek M. Says:

    It sounds like anyone will be able to make someone a 'member'. The textbox will remind people no to, unless they are supposed to be doing so. But it seems that, through a malicious act or a mistake, this field can be change at the wrong time by the wrong people.

    Will there be a need for an oversight/review loop for this? Perhaps a weekly report of all 'new members' that will be double-checked? Or, can a value change in this field trigger a notification to someone for immediate review?

  2. nairdo Says:

    Yes, since anyone with edit permission on the person/family part can change someone to a "Member" we are planning on auditing it.  Thankfully, with the excellent history log of changes that Arena maintains, we'll be easily able to create a report that shows when someone has changed a person to a Member.

  3. Jon Edmiston Says:

    Just an FYI... there's a table core_member_status_history that gets updated every time someone's member status is changed.  It stores the person_id of the changed person along with the login of the person who made the change and the member status it was changed to.

    We added this table so we could track the growth patter of our congregation.  Our thoughts were to eventually build in metrics to each tag/group/etc that shows how many people changed from Attendee to Member.  Or better yet Participant to Attendee (in our church that means something like does something on the campus to attends church).  While not perfect this would help us identify ministries/programs that are outreaching to the community and maturing our attendees.

  4. This End Up Says:

    I yearn for and typically choose only elegant solutions, but in times of desperation it's not beyond

New Comments to this post are disabled

Powered by Community Server, by Telligent Systems