Photo directories and fellowshipping roles

Discuss questions around local unit policies for membership (creating records, transferring records, etc.) This forum should not contain specific financial or membership information.
mogura-p40
New Member
Posts: 4
Joined: Wed Jul 29, 2009 8:38 pm
Location: Salt Lake City, UT, USA

Photo directories and fellowshipping roles

#1

Post by mogura-p40 »

Hi,

I was recently called as a 'Technology Specialist' to my ward's 'Welcoming Committee'.

My ward is a SLC-located YSA-specific ward, focused at university students.

Most if not all of the companion wards in my stake and adjoining stakes have traditionally utilized several tools to increase fellowshiping in these very high turnover units. One of the most critical objectives is to maintain a names-to-faces awareness by the ward's leadership of the constantly changing congregation.
  1. Each Bishop has a large whiteboard in their office with all (active only?) members photo's with magnets to provide an immediate visual overview of present ward organization. Pictures are approximately 1.5"x2" and have the member's name printed on them.
  2. The ward website is frequently used to generate a hard-copy of what is humorously called the 'Ward Menu', as even us kids can grudgingly admit that having a hard-copy list of names and faces can often be easier to browse than an electronic form.
  3. A variant of 1 and 2 is also desired, eg a high-density page(s) of thumbnail pictures with only names.
My Bishopric has recently tasked the Welcoming Committee in general, and me in specific, to devise a mechanism to efficiently generate several different photo-centric tools for different purposes.
  1. Pictures for the whiteboard need to be ready for display no later than the Tuesday following the new member's first Sabbath of attendance (when they submit their new member information)
  2. A directory with photos needs to be available for print on demand. This can be generated from the 'All Members with Photos' view from the Ward web site if necessary.
  3. An expanded directory for Bishopric use is also desired. This would add the names of currently assigned home teachers, current calling and date of sustaining, and a yes/no indicator of whether an MRN is present for the member.
The Y/N note about MRN is because the Bishop can only give Temple Recommend interviews to members for which the unit has records of. This is not intended to replace or even supplement any of the records involved in the interview process, rather it is used to indicate that records had not yet been recieved for the individual at the time of the last printing, so the Bishop should check other records directly before proceeding. Quite frequently, members will ask for temple recommend interviews during the 'Meet the Bishop' first meeting, it's easy enough to catch those cases, but the week following can get confusing when you've had a net change of over a hundred members in a 3~4 week window.

As this project has snowballed over the past month, along with the new school year triggering a significant membership shift, there's been several issues come up that I've been uncertain as to where to find answers to. I'm sure there's a policy or explanation for them, I'm just not sure where to look or who to ask.
  1. What is the policy regarding publication of birthdates, or where can I find the policy? I've seen directories from many-many years ago that dropped the year for members older than 18 or 21, is that still usable or should it be only visible to the Bishopric/Leadership?
  2. Is coordinating a project like this delegatable to a non-leadership calling? Can it be done by non-clerks with approval by the Bishopric? Is there a field-by-field policy of what may and may not be delegated?
  3. Can MLS make custom print layouts, and integrate photos from external (linked?) files, or is it limited to custom report queries only?
  4. Can Custom Reports be saved as digital files, or only printed as hard-copies?
  5. I'm aware of the policy directing that unit 'business' should not be done on any public-facing provider other than *.lds.org (although I don't have the reference handy), what restrictions are there on processing the data on a personal computer with the objective of creating alternative print layouts?
  6. Is the Python scripting engine approved for installation on church asset clerk computers? What about Imagemagick? One of the objectives is for the directory system to be maintainable. I've setup less tech-savvy individuals previously with imagemagick, 'in' and 'out' folders, and a batch file for automaticly scaling any digital camera picture for use on the ward website. Python would be ideal for creating a CSV > XML converter to merge the various MLS exports, and then print them.
Thanks.
User avatar
aebrown
Community Administrator
Posts: 15153
Joined: Tue Nov 27, 2007 8:48 pm
Location: Draper, Utah

#2

Post by aebrown »

I can answer a few questions, and others I'm sure will chime in with additional responses.
mogura wrote:3. An expanded directory for Bishopric use is also desired. This would add the names of currently assigned home teachers, current calling and date of sustaining, and a yes/no indicator of whether an MRN is present for the member.

The Y/N note about MRN is because the Bishop can only give Temple Recommend interviews to members for which the unit has records of.

The MLS "Household Report" contains all this information. Because it includes the MRN, you don't really need a separate "Y/N note about MRN" because it will be blank if the record has not actually been received.
mogura wrote:1. What is the policy regarding publication of birthdates, or where can I find the policy? I've seen directories from many-many years ago that dropped the year for members older than 18 or 21, is that still usable or should it be only visible to the Bishopric/Leadership?

I'm not sure where to find such a policy.
mogura wrote:2. Is coordinating a project like this delegatable to a non-leadership calling? Can it be done by non-clerks with approval by the Bishopric? Is there a field-by-field policy of what may and may not be delegated?

There is certainly no field-by-field policy of what may be delegated. I believe the bishop has wide latitude in making assignments as long as he preserves confidentiality appropriately.
mogura wrote:3. Can MLS make custom print layouts, and integrate photos from external (linked?) files, or is it limited to custom report queries only?

MLS can make custom reports, but there is very limited flexibility of layout. There is no ability to integrate photos from external files. There are various MLS Export files (CSV format), or the result of any custom report can be exported as a CSV, so customized applications could be created to manipulate and format this data.
mogura wrote:4. Can Custom Reports be saved as digital files, or only printed as hard-copies?

Every ward or stake administrative computer should have PDF print driver called CutePDF, which can be used to save a PDF image of custom reports. Also, as I mentioned above, the custom report data can be saved as a CSV.
mogura wrote:5. I'm aware of the policy directing that unit 'business' should not be done on any public-facing provider other than *.lds.org (although I don't have the reference handy), what restrictions are there on processing the data on a personal computer with the objective of creating alternative print layouts?

The policy can be found at Authorized Church Web Sites. The restrictions on transporting or processing confidential data can be found in Policies and Guidelines for Computers Used by Clerks for Church Record Keeping (the Security section), which says that such information should be password protected and transmitted only to authorized people for Church use.
mogura wrote:6. Is the Python scripting engine approved for installation on church asset clerk computers? What about Imagemagick? One of the objectives is for the directory system to be maintainable. I've setup less tech-savvy individuals previously with imagemagick, 'in' and 'out' folders, and a batch file for automaticly scaling any digital camera picture for use on the ward website. Python would be ideal for creating a CSV > XML converter to merge the various MLS exports, and then print them.

As you can also read in the policy document, additional software may be installed with proper approval. Work with your stake technology specialist, who can get the appropriate approval from the stake president.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#3

Post by RossEvans »

You might want to look at the MLS Companion application, which includes a feature for importing photos. (Not sure about printed reports.)

Also, this thread -- Ward Photo Directory Template -- has some ideas for a photo directory.
russellhltn
Community Administrator
Posts: 34417
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

#4

Post by russellhltn »

mogura wrote:
  1. What is the policy regarding publication of birthdates, or where can I find the policy? I've seen directories from many-many years ago that dropped the year for members older than 18 or 21, is that still usable or should it be only visible to the Bishopric/Leadership?
  2. Is coordinating a project like this delegatable to a non-leadership calling? Can it be done by non-clerks with approval by the Bishopric? Is there a field-by-field policy of what may and may not be delegated?
I know of no policy. This is all "bishop's prerogative". I'm not sure who is raising this concern, but as a suggestion, you may want to consider calling this individual as an "assistant clerk". I don't know of anything preventing the ward from having multiple membership clerks. I know some members are very sensitive about their information. So doing it this way should prevent any issues now or in the future.

mogura wrote:I'm aware of the policy directing that unit 'business' should not be done on any public-facing provider other than *.lds.org (although I don't have the reference handy), what restrictions are there on processing the data on a personal computer with the objective of creating alternative print layouts?
I don't know of any policy. However, I would be of the opinion that it should require the bishop's approval and with full disclosure to the bishop of all the information that's being taken to this personally-owned computer.

Note that it is forbidden to run MLS with live data on a personally-owned computer as well as trying to reverse-engineer the MLS data files.
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.

So we can better help you, please edit your Profile to include your general location.
mogura-p40
New Member
Posts: 4
Joined: Wed Jul 29, 2009 8:38 pm
Location: Salt Lake City, UT, USA

#5

Post by mogura-p40 »

Thanks for the comments. I'm aware of CutePDF, good to know it's available on clerk machines.

Just to clarify a couple things, the Bishopric called me as a member of the Welcoming (Fellowshipping) Committee, with the task of "Get the data from the clerks minus ordinance data and make these following types of resources, in as transferable and maintainable manner as possible."

The two primary technical requirements are that I need to integrate pictures (Can pictures be integrated at all into MLS?) and make specific print layouts (appears to not be possible in MLS presently?). I can of course do that all in python and xml/xsl.

Observations:
  1. This project is not to make an alternative non-MLS records source, rather it is only intended to visually layout the MLS derived data in an alternate format, and combine with an external source of pictures. I guess this meets the requirements for MLS being the sole source of data? Essentially, the objective is that the ward clerk can generate new reports > formatted directories on demand from current MLS data, the interim XML step is only to feed the XSL template.
  2. For data security, does locking the device with secure user accounts suffice for transferring data to a non-church asset, or does the data need to be data-level secured in addition to any system-level discretionary user access? I consider the policy re PDA's to apply as well to non-PDA devices used to analyze 'church information', but it's not clear whether the requirement is at the data-level or if system-level is sufficient.
Church information downloaded to personal digital assistants (PDAs) for authorized use by priesthood leaders should also be password protected.
Responses to Alan_Brown:
  1. 'Household Report': The current plan is to append the list of new members onto the bottom of the list from MLS for the purposes of the photo directory. As such, there will be individuals in the Bishopric's directory that may not have records in the ward yet as of last printing. This is only a convenience index indicator, and doesn't replace the more detailed (and authoritative) records report.
  2. 'Birth dates': Wiki suggests that birth-year of adults is 'sensitive', no reason to consider it otherwise. Shouldn't be a challenge to throw a LEN slicer at it.
  3. 'Column delegation': Future members with directory maintenance responsibility may not be as tech-savvy, so if the data is cleaned as much as possible there's less risk of problems. The less they have to manage, the better.
  4. 'Custom layouts': This is the core objective of this assignment.
  5. 'Policies': Thanks for the links, my personal policy is to insist on the actual policy, rather than 'wing it'. :)
  6. 'Software': At this point, the only things I'm considering is Python, Imagemagick, and my own developed .xml, .xsl, .py, and .html files. Python's license is here: http://www.python.org/download/releases/2.6.2/license/ and imagemagick's is here: http://imagemagick.com/script/license.php Both are as far as I can tell should be acceptable for church use. My files are free-domain and entirely my own work.
Responses for BoomerBubba:

Thanks for the links. MLS Companion is rather over-kill for this project, only directories and pictures need processing, and it's intended to be done by non-clerks and non-tech savvy members.

The photo directory thread was very helpful too, but I think my fellow nerds there have way over complicated what it takes to generate photo directories. I'll post the code later today for what I've created, the photos directories can be viewed and printed from any XML rendering web browser on Mac, PC, or Linux without installation of any software.

Responses to RussellHltn:
  1. I'm raising the question, as it's a random niggly stuck in my head from when as a little child watching my dad do clerk work "Daddy, why don't the grownups have birthdate years?" I heard it was policy, just wanted to confirm that as opposed to 'tradition'.
  2. The absolute most that would be distributed from the clerk's machine would be the Organization, HT/VT, and Membership (without Ordinance data) CSV exports. The goal is that a python script on the clerk's machine will mash them together into an XML file, which can then be sent to designated members with the XSL files and pictures.
Imagemagick's purpose is to resize and crop random source pictures to ward web site demension requirements. This is not needed for photo directories since HTML attributes for the IMG tag can control display sizes.
greggo
Member
Posts: 286
Joined: Thu Jan 24, 2008 9:36 am
Location: Battle Creek, MI

#6

Post by greggo »

mogura wrote:
  1. What is the policy regarding publication of birthdates, or where can I find the policy? I've seen directories from many-many years ago that dropped the year for members older than 18 or 21, is that still usable or should it be only visible to the Bishopric/Leadership?

When I was creating a ward directory several years ago, I remember reading a policy in the church handbook (no access to one now, so I can't give the page no.) that publications should not include individual's birthdays (even with the birth year deleted) without their permission. But I've never heard of anyone not giving permission when asked.
User avatar
aebrown
Community Administrator
Posts: 15153
Joined: Tue Nov 27, 2007 8:48 pm
Location: Draper, Utah

#7

Post by aebrown »

mogura wrote:I need to integrate pictures (Can pictures be integrated at all into MLS?)
No, there is no ability to store pictures in MLS. So you'll have to store pictures externally and figure out how to link them. To link, there obviously has to be some unique key; the MLS membership export file has a column called "Indiv ID" that you might want to use, since names might be a bit tricky to reliably link on. You might find the wiki article Export (MLS) helpful, as it details each field of the export, and then you can tell the clerks which non-sensitive columns you need.
mogura wrote: and make specific print layouts (appears to not be possible in MLS presently?). I can of course do that all in python and xml/xsl.
Indeed it is not possible to make specific print layouts in MLS. Since MLS doesn't have pictures, using MLS for layout really isn't an option anyway.
mogura wrote:For data security, does locking the device with secure user accounts suffice for transferring data to a non-church asset, or does the data need to be data-level secured in addition to any system-level discretionary user access? I consider the policy re PDA's to apply as well to non-PDA devices used to analyze 'church information', but it's not clear whether the requirement is at the data-level or if system-level is sufficient.
You quoted the relevant policy for PDAs. You'd have to consult with your local priesthood leaders for local interpretation, but in my opinion, since a PDA would most likely have only system-level passwords, that would be sufficient in this case as well.
mogura wrote:Imagemagick's purpose is to resize and crop random source pictures to ward web site demension requirements. This is not needed for photo directories since HTML attributes for the IMG tag can control display sizes.
There is a standard application recommended by the Church for image manipulation called Photofiltre that can be loaded on the ward computer with no extra permissions (your stake technology specialist can download it from mls.lds.org). But if you want to use Imagemagick, as I mentioned previously, just work with your STS for permission, as you would need to do for Python, anyway.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#8

Post by RossEvans »

Alan_Brown wrote:No, there is no ability to store pictures in MLS. So you'll have to store pictures externally and figure out how to link them. To link, there obviously has to be some unique key; the MLS membership export file has a column called "Indiv ID" that you might want to use, since names might be a bit tricky to reliably link on. You might find the wiki article Export (MLS) helpful, as it details each field of the export, and then you can tell the clerks which non-sensitive columns you need.
That is what I would do. One thing I wonder about is at what point MLS enters a new record and thus assigns an Indiv ID. In the case of a new ward member who shows up on Sunday, triggering the clerks to request the record, does that get captured in the MLS export file immediately, before CHQ responds? I think so, but would need to verify that.

One more gotcha to consider: In order to get a sanitized export file from the clerks in a reliably consistent format, someone should probably write a script for them to use to filter the MLS export file. They can do it manually, but it would be error-prone. Also, editing the export file manually would probably be done in a spreadsheet, which would alter the internal format of the file.
mogura-p40
New Member
Posts: 4
Joined: Wed Jul 29, 2009 8:38 pm
Location: Salt Lake City, UT, USA

#9

Post by mogura-p40 »

Currently I'm using the Individual ID to track pictures, though I realized there's a risk of theoretically a moved-out ID could be reused on a move-in. I think rather, I'm going to suggest using an MLS custom field, or have a separate spreadsheet lookup. I might do that anyway to track website picture id's.

Here's the python code I currently have, this reads directly from the MLS exported CSV's and makes an XML file that's also purged of any ordinance data. For new move-ins without an Individual ID (externally appended from the weekly photo index) the Individual ID element in the XML file is populated with the camera image file name.

Code: Select all

import csv
import xml.dom.minidom

## open the membership export file *WARNING!* Contains substantial confidential ordinance data!
# Column AB (27) is birthday, the last non-ordinance column in the spreadsheet (9/13/2009)
f = open('Membership-purged.csv', 'r')
f2 = csv.reader(f)

## open home teaching export file. I think python may be having problems with leading null fields, or at least my primative code.
h = open('HomeTeaching.csv', 'r')
h2 = csv.reader(h)

## open visiting teaching export file. column format differs from HT.
v = open('VisitingTeaching.csv', 'r')
v2 = csv.reader(v)

## open organization callings export list. This is ordered by calling, not by member. Much work todo on matching.
o = open('Organization.csv', 'r')
o2 = csv.reader(o)

## create logic XML object
doc = xml.dom.minidom.Document()

## add root object to new XML object
ward = doc.createElement("ward")
## add embedded stylesheet reference. Replaced by javascript code in HTML redirect pages to load variant XSL files.
#doc.appendChild(doc.createProcessingInstruction("xml-stylesheet", "type=\"text/xsl\" href=\"members.xsl\""))
doc.appendChild(ward)

## function to create and populate data elements for member elements.
def memobj(id, num):
    member_elem = doc.createElement(id)
    member.appendChild(member_elem)
    member_data = doc.createTextNode(row[num])
    member_elem.appendChild(member_data)

## function (deprecated) to store member data as attributes of the member element, rather than child elements. TODO: remove entirely.
def memattrib(x):
    y = doc.createAttribute('id')
    x.setAttributeNode(y)
    z = x.setAttribute('id',row[0])
        
    y = doc.createAttribute('name')
    x.setAttributeNode(y)
    z = x.setAttribute('name',row[1])

## function (largely todo) to merge ht/vt data with the member object. HTP is having problems in python not handling leading cells having no value.    
def memteach():
    i = 0
    for hrow in h2:
        
        if i == 0:
            hheader = hrow
        else:
## debugging code            
#            print row[2]
#            print hrow[9]            
#            if ((row[2]) == (hrow[9])):
#                print 'MATCH'
#                print row[2]
#                print hrow[9]

            x = doc.createElement('ht1')
            member.appendChild(x)
            y = doc.createTextNode(' ')
            x.appendChild(y)
            
            x = doc.createElement('ht2')
            member.appendChild(x)
            y = doc.createTextNode(' ')
            x.appendChild(y)
#                break

            break
## This code 'works' in hi-lighting members without hometeachers. However, the csv reader was skipping rows with leading empty fields, which is most of them. So todo.
#            else:
#                print 'NO MATCH'
#                print row[2]
#                print hrow[9]            

#                x = doc.createElement('ht1')
#                member.appendChild(x)
#                y = doc.createTextNode('NO HOME TEACHER')
#                member.appendChild(y)
                
#                x = doc.createElement('ht2')
#                member.appendChild(x)
#                y = doc.createTextNode('NO HOME TEACHER')
#                member.appendChild(y)
#                break
        i += 1

## functions for handling callings (DEPRECATED?). Todo: merge in memdata()
def memcall():    
    x = doc.createElement('call')
    member.appendChild(x)
    y = doc.createTextNode(' ')
    x.appendChild(y)
    
    x = doc.createElement('sustain')
    member.appendChild(x)
    y = doc.createTextNode(' ')
    x.appendChild(y)

## function to populate member object's data children elements. Can be used by implication to create an ordinance-data purged file from unpurged csv export files.
def memdata():
    memobj('id',0)
    memobj('name',2)
## todo: convert stored data to boolean    
    memobj('mrn',3)
    memobj('phone',7)
    memobj('email',9)
    memobj('addya',10)
    memobj('addyb',11)
    memobj('city',13)
    memobj('zip',14)
    memobj('state',15)
    memobj('gender',26)
## todo: trim year    
    memobj('bday',27)
    
rownum = 0
for row in f2:
    if rownum == 0:
## todo: use this to populate names of xml elements        
        header = row        
    else:
## create member element        
        member = doc.createElement("member")
        ward.appendChild(member)
## append data for member        
        memdata()
#        memteach()
#        memcall()
    rownum += 1
    
xdoc = open('testxml.xml', 'w')
doc.writexml(xdoc, indent="    ", addindent="    ", newl="\n")
xdoc.close    
f.close
h.close
v.close
o.close
And the corresponding .XSL data to render the photo lists, currently configured for 4x across whiteboard-ready printing (see comments for 8x thumbnail pages)

Code: Select all

<?xml version="1.0" encoding="utf-8"?>

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<!-- ======= Begin loops ======== -->    

<xsl:template match="/">
<!-- Multiply by 4 for large whiteboard pictures -->
<!-- Multiply by 2 for small thumbnail sheets -->
    <xsl:variable name="iwidth" select="((12*3)*4)"/>
    <xsl:variable name="iheight" select="((12*4)*4)"/><!-- 192x144 -->
<html>
    <head>
        <title>38th Ward Member Directory</title>
<!--        <link rel="stylesheet" href="./generic.css" type="text/css" />        -->
    </head>
<body>
    <table width="100%" border="0">
        <colgroup>
            <col width="1*"/>
            <col width="1*"/>
            <col width="1*"/>
            <col width="1*"/>
<!--            
            <col width="1*"/>
            <col width="1*"/>
            <col width="1*"/>
            <col width="1*"/>
-->            
        </colgroup>        
        <xsl:for-each select="ward/member">
            <xsl:if test="(position() mod 4) = 1">
                <tr>
                    <td align="center">
                        
                        <img>
                            <xsl:attribute name="src">
                                ./pics/<xsl:value-of select="id"/>.jpg
                            </xsl:attribute>
                            <xsl:attribute name="width"><xsl:value-of select="$iwidth"/></xsl:attribute>                    
                            <xsl:attribute name="height"><xsl:value-of select="$iheight"/></xsl:attribute>
                        </img>
                        

                        <b><xsl:value-of select="name"/></b>
                    </td>
                    <td align="center">
                        <img>
                            <xsl:attribute name="src">
                                ./pics/<xsl:value-of select="following-sibling::member[1]/id"/>.jpg
                            </xsl:attribute>
                            <xsl:attribute name="width"><xsl:value-of select="$iwidth"/></xsl:attribute>                    
                            <xsl:attribute name="height"><xsl:value-of select="$iheight"/></xsl:attribute>                
                        </img>
                        
                        
                        <b><xsl:value-of select="following-sibling::member[1]/name"/></b>
                    </td>
                    <td align="center">
                        <img>
                            <xsl:attribute name="src">
                                ./pics/<xsl:value-of select="following-sibling::member[2]/id"/>.jpg
                            </xsl:attribute>
                            <xsl:attribute name="width"><xsl:value-of select="$iwidth"/></xsl:attribute>                    
                            <xsl:attribute name="height"><xsl:value-of select="$iheight"/></xsl:attribute>                
                        </img>
                        
                        
                        <b><xsl:value-of select="following-sibling::member[2]/name"/></b>
                    </td>
                    <td align="center">
                        <img>
                            <xsl:attribute name="src">
                                ./pics/<xsl:value-of select="following-sibling::member[3]/id"/>.jpg
                            </xsl:attribute>
                            <xsl:attribute name="width"><xsl:value-of select="$iwidth"/></xsl:attribute>                    
                            <xsl:attribute name="height"><xsl:value-of select="$iheight"/></xsl:attribute>                
                        </img>
                        
                        
                        <b><xsl:value-of select="following-sibling::member[3]/name"/></b>
                    </td>
<!-- Enable this block for 8x (thumbnail) rows
                    <td align="center">
                        <img>
                            <xsl:attribute name="src">
                                ./pics/<xsl:value-of select="following-sibling::member[4]/id"/>.jpg
                            </xsl:attribute>
                            <xsl:attribute name="width"><xsl:value-of select="$iwidth"/></xsl:attribute>                    
                            <xsl:attribute name="height"><xsl:value-of select="$iheight"/></xsl:attribute>                
                        </img>
                        
                        
                        <b><xsl:value-of select="following-sibling::member[4]/name"/></b>
                    </td>
                    <td align="center">
                        <img>
                            <xsl:attribute name="src">
                                ./pics/<xsl:value-of select="following-sibling::member[5]/id"/>.jpg
                            </xsl:attribute>
                            <xsl:attribute name="width"><xsl:value-of select="$iwidth"/></xsl:attribute>                    
                            <xsl:attribute name="height"><xsl:value-of select="$iheight"/></xsl:attribute>                
                        </img>
                        
                        
                        <b><xsl:value-of select="following-sibling::member[5]/name"/></b>
                    </td>
                    <td align="center">
                        <img>
                            <xsl:attribute name="src">
                                ./pics/<xsl:value-of select="following-sibling::member[6]/id"/>.jpg
                            </xsl:attribute>
                            <xsl:attribute name="width"><xsl:value-of select="$iwidth"/></xsl:attribute>                    
                            <xsl:attribute name="height"><xsl:value-of select="$iheight"/></xsl:attribute>                
                        </img>
                        
                        
                        <b><xsl:value-of select="following-sibling::member[6]/name"/></b>
                    </td>
                    <td align="center">
                        <img>
                            <xsl:attribute name="src">
                                ./pics/<xsl:value-of select="following-sibling::member[7]/id"/>.jpg
                            </xsl:attribute>
                            <xsl:attribute name="width"><xsl:value-of select="$iwidth"/></xsl:attribute>                    
                            <xsl:attribute name="height"><xsl:value-of select="$iheight"/></xsl:attribute>                
                        </img>
                        
                        
                        <b><xsl:value-of select="following-sibling::member[7]/name"/></b>
                    </td>                    
-->                
                </tr>
            </xsl:if>
        </xsl:for-each>
    </table>
</body>
</html>  

</xsl:template>


</xsl:stylesheet>
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#10

Post by RossEvans »

mogura wrote:Currently I'm using the Individual ID to track pictures, though I realized there's a risk of theoretically a moved-out ID could be reused on a move-in.
From the many challenges you face in this project, you can eliminate that one. The Indiv ID field is not reused if a member moves out. Such keys are simply retired.
Post Reply

Return to “Membership Help”