Create a new table with fields to hold the scheduling data for an individual:

tc_scheduling

• indiv int(16)
• notes text
• interview_type (hit, ppi)

If an indiv does not have an entry in the tc_scheduling table, he shows up on the lists with the lowest priority without any notes. As soon as you enter notes or change the priority, an entry is made into the table. Each indiv would have at most 2 entries in the table, one for each type of interview. As soon as an interview is scheduled, the entries are removed from the eq_scheduling table, and the indiv shows up with the lowest priority again in the interview lists until he is attempted to be scheduled again.

Now that we have the database set up correctly, we can show more information about hometeaching history. I would like to see a few different views:

1. For a particular family
   1. What companions have been assigned to home teach them
   2. What months have they been visited
2. For a particular companion
   1. What families have they been assigned
   2. Who have their companions been
   3. What families were visited each month

There are probably other views we can create, but I think these will be the most useful.

We no longer need to reference a special entry in the eq_presidency table with the eq_ppi and eq_visit table changes (issue #6 and issue #7).

• Remove the eqpres field from the eq_presidency table
• Modify the directions on the admin page to remove references to it
• Change the email tool to understand how to send an email to the EQ presidency. Query the eq_presidency table, and collect the email addresses for each presidency member when sending email to the presidency.
• The scheduling tool will need to special case the creation of the EQ presidency visit table.

When you go to "Schedule PPIs", only the EQ president's schedule is shown. We need to show all presidency members. Perhaps we can add an option to the config file to say who can do PPI interviews (EQ pres only, pres + counselors, pres + counselors + secretary) So that it looks right depending on how the quorum operates.

Right now, anybody with access to tc can see all of the pages. It would be nice, however, to restrict access to some pages if the user is not a member of the presidency. A config page that lists each of the users and which pages they have access to would be very useful. For example, if we have an activities coordinator, I could see them needing Willingness, Participation, Activities, Assignments, Directory, and Callings. I would not want them seeing HomeTeaching, Interviews, PPIs, Visits, Scheduling, Attendance, or Admin. There may be very private/personal information contained on those pages.

I think the phpgroupware UserGroups settings could be used for this (as long as those groups are available in our app - not sure how that is done), at least to create access groups and associate users with those groups. It looks like Admins, Default are created by default.

I would also like to add a table that just stores historical companionship data - who the companions where, what families did they home teach, date companionship was created. This would get updated any time the import script was run and would only contain changes (initial import would put all companionships into this table). This would be nice data so we could create custom reports (linking with other tables):

1. who were this family's hometeachers for the last N months
2. who did this companionship hometeach for the last N months, and which ones did they visit

This will depend on issue #21

It would be nice to have a page that tracks the progress of prospective elders as they progress in the priesthood. Still need to think of what things to track...

When you are scheduling home teaching interviews, the aaronic priesthood companions that are < 18 yrs should also be available in the "Elder" dropdown list. Both companions should be in the interview.

We just need to include all rows in eq_aaronic where valid=1.

One thing that we are doing as a presidency is to do hometeaching interviews once a quarter. For that, it would be convenient if the hometeaching interviews page used fixed quarters rather than rolling quarters.

A fixed quarter setting would show months based on fixed quarters of the year

• Jan, Feb, Mar
• Apr, May, Jun
• Jul, Aug, Sept
• Oct, Nov, Dec
  Then, when I changed the filter to show multiple quarters, I would see the months for those fixed quarters. It is September now, so 2 quarters would be Apr-Sept. In October, it would be Jul-Dec. I still want the individual months so we can put the date of the interview in the month and easily see what month the interview took place - should help to balance how many interviews we do each month.

Others may do them more frequently (like monthly), and just want to see rolling quarters. It is September now, so 2 quarters would be Apr-Sept. In October, it would be May-Oct.

I didn't see any other pages that use quarters the way hometeaching interviews does. However, if there are others, we could do the same for them.

tc_companionship uses the mls companionship id to keep track of companionships. This should not be happening since the companionship id can change as companionships change. Just like we have an inidividual id that is different than the mls indiv id, we should have a companionship id that is different than the mls companionship id.

It would be nice to see everybody in the EQ that have callings and what their callings are.

I propose we change the page so that there is a drop-down list of ways you can sort the list of callings and then click a "refresh" button.

Drop-down list items

• By name
• By organization
• In our stewardship

the scheduling app emails the interviewer when an appointment is made with a member of the quorum, but that member doesn't get an email.

Add prospective flag to the eq_elder table so we can track prospective elders properly.

I entered some PPIs and tried to set the interviewer to one of the counselors. It would "save" it without any complaints, but when I viewed the PPI again, it is always set back to the president. (counselors are available in the dropdown)

Since we're making a lot of database changes and we are the only ones using 3rd Counselor right now, let's remove the old release tags and start over with version 1.0.0. We will want anybody new to use this version, not a version that is older. This would also eliminate the need for the upgrade scripts that are there right now (next database change will need an upgrade script).

Inherent in this is changing from a X.Y version scheme to an X.Y.Z scheme

• A new "type" field should be added to the eq_visit table with enumerated values "hometeaching" and "presidency".
  • The upgrade script should set all visits currently marked as companionship=0 with "type" "presidency" and all other visits should set to "hometeaching".
• Add 2 new fields to the eq_visit table to accomodate "custom" companionship visits (presidency visits for example). Call these fields "elder1" and "elder2".
  • The upgrade script should add these new fields and default their values to NULL.

I'm thinking we should default the priority of visits/interviews not completed yet to the lowest priority. Granted, if you haven't visited any of them, they have the highest priority to be visited. However, if they are all the same priority, and that priority cannot be increased, they essentially have no priority. Here would be my general workflow - perhaps it would be different for others:

1. Have a list of people/families to interview/visit
2. Select a few that I need to interview/visit in the first round
3. For each of those people/families, i would increase the priority to draw attention to them and add a note - perhaps to the pres member I want to do the visit/interview

If I am not the one doing the workflow above, I would need to see if there are any people/families I have been assigned to visit/interview. It would make it easy to look at the list and see that the people/families at the top of the list have the highest priority and can quickly look at the notes to see if it is an assignment that I need to fulfill.

Perhaps the best way to implement this is to have a setting in the config file that says - "initialize visit/interview priority" and have highest/lowest be the available values. That way, if someone has a workflow that is different from me, they can implement it quickly.

the indentation in the code is a mixture of tabs and spaces that are not uniform, thus making it hard to see the structure of the code. Change it so that

1. code blocks are indented with tabs
2. alignment of parameters on multiple lines are indented with tabs to the code block, then spaces to do the alignment.

Just a cosmetic thing, but I'm kinda anal :)

In our presidency, we like to schedule hometeaching interviews and ppi's during specific blocks of time on certain days of the month. All members of the presidency are there. It would be nice on the scheduling page to be able to select a date/time and then apply it to all members of the presidency at once. Here's what I'm envisioning would appear after all of the individual schedule blocks:

Multi-person : Appointment Slots

• Date
• Time
• Location
• list of everybody in the tc_presidency table with checkboxes next to them

When you click "Save Schedule", each individual selected gets a schedule item in their list with the same date/time/location. The form would then be blank and ready for another entry - it doesn't keep track of schedules it entered - it is just for input.

This could be used for ht interviews, ppi's, or other things in the future that might have 1 or more people needing to be there.

eq_ppi table should be renamed to tc_interview table

• eqpresppi field should be changed to an enumerated type field called "type" with enumerated values "hti" and "ppi".
  • The upgrade script should set all visits currently marked as eq_presppi with "type" "ppi" and all other visits should set to "hti".
• ppi field should be changed to "interview".
  • The upgrade script should rename the field.
• The UI will need to change to enable companionship interviews to be scheduled and recorded.
  • Add a setting to the tc_config file to specify if "hti" type interviews are done as companionships or individuals.
  • Add a setting to the tc_config file to specify who does "ppi" type interviews (president, president + counselors, president + counselors + secretary).   + The UI will need to be updated to only list the valid interviewers for "ppi" type interviews based on this setting.
  • If hometeaching interviews are done for a companionship, the tool should make 2 entries in the tc_interview table for each individual with the same notes, date, type, and interviewer field values.
  • If hometeaching interviews are done for a companionship, the scheduling tool should let you select the companionship, rather than the individual. That way, you only have to manually schedule one interview, even though the tool would create both entries in tc_interview

Right now, the scheduling app shows a scheduling table per district leader. If there is one person who is district leader for multiple districts, they should only have one scheduling table. Perhaps we should have the scheduling app have tables for each unique indiv_id, not for the district leaders. That way, if you have district leaders who are not part of the presidency, you can have scheduling tables for each of the presidency members and for each of the district leaders.

This would mean the pages for scheduling interviews/visits would need to see who in tc_admin is a district leader, or presidency member and pull their schedule out.

This work is related to

• Issue #4 scheduling PPIs doesn't list enough of the presidency
• Issue #8 remove EQ Presidency type from the eq_presidency table

We don't use birthday for anything in 3rd Counselor and it is pretty private information. Let's remove this so we reduce our liability of private data leaking out somewhere.

Neither MLS nor 3rd Counselor provide a way for you to rearrange hometeaching companionships in a way that is non-permanent and provides an easy way to see how the changes affect the overall picture. This feature would provide a hometeaching sandbox that would allow you to change companionships, and the familes they are assigned. Any changes made here would apply to the sandbox only. Once you are happy with the changes, you would manually enter them into MLS, export the regular files from MLS and import them into 3rd Counselor in order to see them in the regular hometeaching page.

Database organization:

tc_family_sandbox

• auto-incrementing id
• individual (id that would link to tc_individual)
• companionship (id that would link to (tc_companionship_sandbox)

tc_companionship_sandbox

• auto-incrementing id
• tc_companionship (id that would link to tc_companionship)
• district

tc_companion_sandbox

• companion (auto-incrementing id)
• individual (id that would link to tc_individual)

tc_district_sandbox

• district (auto-incrementing id)
• supervisor (id that would like to tc_individual)

Details:

• The "sandbox" link would appear on the Hometeaching page.
• A "reset" button would clear out the above tables, and repopulate them to match the current state of hometeaching companionships and families. The first viewing of this page would be blank, and pressing the "reset" button would be required to see any data (simplifies logic to populate the tables on "first load"). Thus, no changes to the import script are needed.
• A table would be displayed at the bottom of families unassigned to any companionship
• Moving a family from one companionship would require adding that family to the new companionship, and then clearing that family out of the old companionship.
• A save button would need to be pressed in order for any of the changes to take affect and be retained for the next page load.

Upgrade Path

• Script to create the tables
• In the future, any changes to the table structures would be made in the upgrade script. No data migration should take place as the user can simply press the "Reset" button to get the data loaded properly