5 - DVS Certification (design document) - redacted version.pdf

DOCUMENT AND VOTING SYSTEM (DVS) DESIGN DOCUMENT

The best approach to analyzing DVS Design is to step through the sequence of initialization, distribution and in the case of Tally Votes, closed, within DVS. The first step is OCS receiving a docs submitted to OCS via DVS Staging as pdfs. On limited occasions, OCS will turn word docs into pdfs.

. The DVS database is a mail-in database within the FEC Directory (there is also a DVS TEST database which is also mail-in and shown below)…

DVS…

DVS TEST…

In order to easily distinguish and remember the mail-in name, an alternate name was created for DVS TEST. This also avoids confusion with a prior version of DVS TEST which is located elsewhere. Please note that the current DVS TEST database resides separately. This was done in order to conduct development and testing within the production server cluster environment.

The process begins with OCS staff receiving a document either via DVS Staging as pdf or on limited occasions, OCS will turn Word documents into pdfs and sending the pdf as a file attachment via email to “Electronic Distribution” as the recipient (the mail-in name for DVS as seen above). Both methods are needed by OCS. OCS staff uses a special naming convention for the pdf name which will be used below.

After the mailing occurs, the first step DVS takes is to automatically convert the incoming memo and file attachment into a DVS Distribution record. This document is then available for data entry through the Distribution form. The scheduled agent which performs this conversion is called “Process Scanned Documents New”…

Note the schedule (“More than once a day”). This agent was originally designed to run when new mail arrives but was converted to run every 5 minutes…

The code parses the Incoming/Scanned view (displaying the latest incoming mail memos (with pdf attachment) sent by OCS). For each record, the Form is converted from Memo to Distribution and the received date and time fields are set…

The code proceeds to analyze the file name of the pdf attachment (this is in a specific format as mentioned above) in the Body field of the incoming memo and sets the Title and DocumentType on the Distribution…

Cleans out mail-specific fields since this is a converted mail memo which was routed…

The final thing the agent does is set the current ActiveCommissioners and ActiveCommissionersLN (LN stands for “Last Name”) on the Distirbution and saves

it. The code after this regarding “EXCLUSION OF COMMISSIONERS…” is moot due to enhancements to the Certifications database and no longer used…

Note how the code goes to the “(InternalAdmin)” view and grabs the “Config- Commissioners” document. This document stores the list of current Active Commissioners and Designated Voters, among other things. Within DVS, go to Maintenance-Configurations. Note the “Config-Commissioners” document and open it…

The primary things this document stores are various forms of the Active Commissioner names as well as the overall list of Designated Voters. Also note the Commissioner Group in NAB and Designated Voters Group in NAB fields. The Commissioners and Designated Voters groups in the FEC Directory list the respective list of current actives for use in the DVS Access Control List…

The Active Commissioners and their respective Designated Voters (DVs) are maintained in the Certifications database. The Certifications database is the hub for setting Active Commissioners which synchronizes with both the FEC Directory and DVS. So at this point, let’s look at how Active Commissioners and DVs are entered in Certifications and how this data is synchronized with FEC Directory and DVS. Go to the Certifications database.

Select Administration – Commissioners in the upper right-hand corner…

This opens the Commissioners view. Note the names of Commissioners, previous and recent, and their Active status (Yes or No)…

Open one of the Commissioner records. Note the input fields, particularly Active (Yes or No) and the Designated Voters. Here is where the specific Designated Voters are indicated for each Commissioner…

The WebQuerySave event of the Commissioner form in Certifications calls the CRD_Refresh_Opener agent. The code in this agent performs all of the Commissioner synchronization between Certifications, FEC Directory and DVS.

Let’s take a look at it. The first thing CRD_Refresh_Opener does is access the DVS database form Certifications…

This will probably be looked at a little later but what DVS does is stores Author and Reader names for all documents. Distribution and Tally Vote document Readers consist of the Commissioner and Designated Voter groups along with the selected Distribution List groups and individuals. The Authors field is limited to the [Distributor] role.

However, each Tally Vote comes with a set of ballots, which are response documents to the Tally Vote. There is one ballot for each active Commissioner indicated when the Tally Vote (TV) was released. The set of ballots include a vote deadline which was entered before distribution on the parent Tally Vote by OCS staff. While a ballot is open, i.e., while the current date/time is before 4:00 PM on the vote deadline, the Authors field on each Ballot consists of the individual Commissioner and their Designated Voters, as indicated in the Commissioner record in Certifications above. The Readers field is set only to the [Distributor] role. When a vote deadline passes, the “Tally Vote Cut off” scheduled agent closes the ballot by moving the Commissioner/DVs from the Authors field to Readers, and leaves only the [Distributor] as Author. The “Tally Vote Cut off” code will be examined later but the bottom-line is that Ballots do maintain the name of the Commissioner and Designated Voters within Authors and Readers fields within DVS. The list of DVs indicated for a Commissioner in Certifications always has to be in synch with the Authors and Readers fields on Ballots in DVS, whether they are open or shut-off.

So back in CRD_Refresh_Opener in Certifications, the code has to update all ballots associated with the now being saved Commissioner record with the DVs listed for the Commissioner. The code sets up the DVS views to find both the closed and open ballots, and initializes the document collection variable which will be used for both…

Not the distributor_array(0)=”[Distributor]”. This will be the first element in all Authors and Readers field and ensures OCS users, who have the [Distirbutor] role, will always have access to all documents. Moving ahead in the code, there is a bit of an abstract concept here, with strings put together with “~~” and “!@#$” strings. The idea behind one of the variables, comm_lno_array_string, is to sort the active commissioners list on last name in DVS, the “!@#$” is the delimiter between active commissioners in the string. Note how the first portion of each Commissioner is doc.CommissionerLastName… comm_lno_array_string=doc.CommissionerLastName(0) + "~~" + doc.CommissionerName(0)+"!@#"

The des_voters_array_string also stores the designated voters for this commissioner as a string, delimited by “!@#$”.

Each string, comm_lno_array_string and des_voters_array_string, will be split on the “!@#$” after all the active commissioners and their dv’s have been appended to each string.

The next step, for the current active Commissioner document, is to set the READERS and AUTHORS , as described before, on the Ballots in DVS. For closed ballots, append to the READERS field distributor_array (set to the [Distributor] role), the current Commissioner (comm_active_doc1.commissionername(0)) and the Commissioner’s DVs (comm_active_doc1.DesignatedVoters)…

Note towards the end of the screenshot above, the “ballots_comm_only_dc” document collection. Some Tally Votes are distributed to the Commissioners Only distribution list. The ballots for this Tally Vote exclude the designated voters, who are not able to even read the ballots. Note that comm_active_doc1.DesignatedVoters is appended to READERS for the ‘regular’ ballots but is not appended and stamped to ballots in the ballots_comm_only_dc document collection. Only the [Distributor] role and comm_active_doc1.CommissionerName(0) are appended to READERS for

Commissioner Only ballots. The code then sets AUTHORS on open ballots, using a similar mechanism for Commissioner Only ballots…

Note the Set comm_active_doc1=comm_active_doc2 and the Wend. This is where the next active Commissioner is processed, where comm_lno_array_string and des_voters_array_string are appended with the next Commissioner’s data and AUTHORS and READERS are set on that Commissioner's ballots in DVS.

The code then splits the accrued comm_lno_array_string and des_voters_array_string values on “!@#$”. The comm_lno_array_string is then populated into the CommissionersLNO field in the DVS Config-Commissioners document (dvs_comm_doc)…

And sorted in there (on the Commissioner last name, remember, it comes before the “~~”). Notice the @Sort in the code below. From there, the Commissioners and CommissionersLN fields are populated by using Right and Left (of “~~”) in the now populated CommissionersLNO field.

The dvs_comm_doc.DesignatedVoters field is populated by splitting the des_voters_array_string on “!@#$”.

Notice the nab_comm_group and nab_des_voters_group assignments to dvs_comm_doc.Commissioners_Group and dvs_comm_doc.DVoters_Group fields, respectively. These are the names of the FEC Directory Groups containing the current active Commissioners and all Designated Voters, respectively. These two groups are used for the DVS Access Control List. They are stored within the Certifications database…click Administration – DVS Integration…

Click DVS Configuration…

And this dialog box appears. Notice the Commissioner Group and DV Group fields, along with the DVS and FEC Directory paths…

The code in CRD_Refresh_Opener sets the nab_comm_group and nab_des_voters_group variables based on the Commissioner Group and DV Group fields above….

These values are then entered into the dvs_com_doc in DVS…

This is followed by the actual Commissioners and Designated Votes NAB groups being updated with members. Note the groups_array values…

Dim groups_array(0 To 1) As Variant groups_array(0)=nab_des_voters_group groups_array(1)=nab_comm_group

Again, these values come form the DVS Configuration record shown above…

And in CRD_Refresh_Opener…

The two groups are then accessed in the FEC Directory . If the group is not found, a new Group dlocument is created…

The members in Group and Designated Voters groups are populated with either group_members_array(0)…All Designated Voters for currently Active Commissioners… group_members_array(1)…All Active Commissioners…

Remember, earlier in the code, groups_members_array is populated in this manner…

So, moving on in CRD_Refresh_Opener, the next portion was added specifically for the Law Manager application owner. It is designed specifically to catch when new Commissioners are added to FEC. Form there, it ensures the names stored in Certifications match those stored in Law Manager. The exact match is required for when Commissioner votes are entered in Law Manager (not a DVS function)…

The rest of the code synchronizes the “Commissioner Group in FEC Directory” and “Designated Voters Group in NAB” values in the DVS Configuration record (in Certifications)…

With the Config-Commissioners record in Certifications…

That concludes the summary of the CRD_Refresh_Opener agent in Certifications and how it synchronizes with both DVS and the FEC Directory. Now, back in DVS, this was explained towards the end of reviewing the Process Scanned Documents New agent, which converts inbound mail memos with a single pdf attachment into a DVS Distribution Record…

Note how it grabs the Commissioners and CommissionersLN fields from the Config-Commissioners document. We just reviewed how those are maintaned in Certifications and synchronized with Config-Commissioners in DVS. Note that Process Scanned Documents New includes a CopyAttachments subroutine. This is no longer used as the inbound Memo itself is converted into a DVS Distribution Record, so the pdf attachment remains with the record, in the Body field.

That summarizes the basics for the Process Scanned Documents New agent and code. There is a module towards the end of the agent which concerns itself with a Commissioner Exclusion List stored in Config-Commissioners. At one time, during a time of transition between active Commissioners, it was necessary to mark even departed Commissioners as Active, temporarily, to valdiate older Certifications for release in Certifications. For example, Commissioner Jones voted on a matter stored in Draft Certifications, departed the FEC so is no longer marked Active, but the Certification needs to be released. OCS staff would then mark Commissioner Jones, using the method outlined above, as Active then submit the Certification.

After the certification is submitted, OCS would mark Commissioner Jones as Inactive again. As this was going on, it was necessary to not include Commissioner Jones as an active Commissioner if a DVS document was being created. Thereofre, DVS was storing an Exclusion List, Commissioners who had departed and were not to be included in future Distributions. Anyways, this all became moot as a mechansim was built for Certifications allowing OCS staff to modify active Commissioners on a case by case basis, inside individual Certifications. The Active

Commissioners will now reflect the current Active Commissioners at all times so there is no need for the Exclusion List. The code remains in PRocess Scanned New (the beginning shown below) but it is not used…

That concludes the processing for Process Scanned Documents New. Now that the incoing mail memo with pdf attachment has been converted to a DVS Distirbution document (using the Distribution form), the document now appears in Working view (in Designer, it is Distirbution Center\Working)…

Note the selection formula in Designer…

The primary part is the Distributed field. Whenever any document is distirbuted in DVS< it receives a 1 in the Distributed field. All documents, including Tally Vote, begin as a Distribution form (as converted to in Process Scanned Documents New). The Supporting form is no longer used. At this point, all Distributuon documents have a Status of Draft (displayed here via exclusion condition…Status!=”APPROVED”). The functionality form this point is performed by OCS from within the Distribution document. It is now time to review the Distribution form, primnarily the action buttons. This is what the Distirbution form initially looks like for the end user (in Edit mode)…

The first fields to look at which affect functionality are the Distribution List and Distribution Members. These groups and individuals will ultimately receive links to this document when Distirbuted by OCS (in the (Distirbute) agent, reviewed later). The Document Type field determines whether this is a straight-forward FYI distirbution (Informational or Meeting) or will have a related Tally Vote document with associated Ballots (Tally Vote)…

First, let’s look at if Informational or Meeting is selected. Notice the Submit button appears at the top of the document…

Let’s look at the code behind Submit. The primary things it does is ensure a Distirbution List is entered, sets the Status of the Informational or Meeting to “Approved” and calls the “Update Distribution Individuals Access List” agent (and runs it on the server)…

The primary function of the “(Update Distribution Individuals Access List)” agent is to ensure that any individual(s) listed as Distribution Members have READ access to DVS via the “DVS_Individuals” group in the FEC Directory. The DVS_individuals group is listed in the DVS NAB with Reader access. This enables these ditribution recipients to read the documents where they are listed (and will be distirbuted links via email). The code adds the Distirbution Member to the group if they are not currently a member…

Note the configdoc=configview.GetDocumentByKey(“Config-Environment”)

Production…

Test…

After the code grabs the FEC Directory (names.nsf), it then accesses the DVS_Individuals group document, using the groupName variable set in the code above as the key. If it does not find the DVS_individuals group, it will create it…

The DVS_Individuals group members are then updated…

Note the call to the “IsMember” and “addGroupMember” methods. These and other customized FEC Directory related Group methods is stored in the “Group” script library…

Now, back to the Submit button on the Distribution form. We have just looked at how the code ensures anybody listed as an individual Distirbution Member is guaranteed access to DVS via the “Update Individuals Distirbution Access List” agent call. The Distirbution document status is changed to “APPROVED” and this moves the document from Working view into the Distribution Center…

Here is the view selection formula for the DIstirbution Center view…

Note the Status = “APPROVED”. Also note the Form=”Distirbution” & DocumentType!=”TallyVote”. What occurs in DVS is that for Tally Vote types on a Distirbution form, a separate Tally Vote document is created and this serves as the primary document for the rest of the life cycle. For informational and Meeting document types, the original DIstirbutiuon remains as the primary document.

Let’s look at the “Create Tally Vote” button on the Distirbution form. This button appears if the user selects “Tally Vote” Document Type…

This button then creates the Tally Vote. This Distribution document remains in the database but is never really used again. So let’s look at the code behind “Create Tally Vote” in the Distirbution form. The first portion shonw below creates the Tally Vote document (db.CreateDocument) and sets numerous fields form values off this Distribution document instantiated as ddoc earlier in the code (Set ddoc = uidoc.Document). In particular, note the VotingDocId field, this field on the Tally Vote will be used to map the Tally Vote back to it’s opriginal Distribution document. The value is set to the Distribution document’s universal id.

The next portion of the code is critical to the Tally Vote and subsequent Ballots relationship. Each active Commissioner will receive a Ballot, which is a child document to this Tally Vote. This will be examined when reviewing the Tally Vote form. However, each of the Commissioner votes and Vote date and time from each Ballot will be loaded into the Tally Vote form at the time an individual Ballot is voted on and submitted. Here is a look at the table in the Tally Vote form where each of the Commissioner Votes will be uploaded and stored…

There can be up to 6 active Commissioners, so up to 6 Ballots are created. Note the format of the field names…the _1, _2, appended to each field name keeps each of the Commissioner names, votes, vote date/time and comment aligned.

So, back in the Create Tally Vote button on the original Distribution form, the first column of Commissioner names (Commissioner_1, Commissioner_2, etc) is populated from the ActiveCommissioners and ActiveCommissionersLN fields form the Distirbution form. If you remember, ActiveCommissioners and ActiveCommissionersLN were populated with the Active Commissioners from certifications during the “Process Scanned Documents New” agent run, which converts the initial incoming email to a Distribution form. Finally, the “Create Tally Vote” button sets the TallyVoteID field on the original Disttibution to the unique document id of the new Tally Vote document. The TallyVoteID field will also be populated on the child Ballots, created form the Tally Vote. This value ties Distirbution, Tally Vote and Ballots all together.

The last button to summarize on the Distribution, there are others but these have been the primary buttons, is “Make Draft”. This is a shared action and sets the status of a Distribution in either the Distribution Center or after it has been released (i.e. not DRAFT status). This is the visibility formula…

The code changes the Status to Draft by calling the ChangeStatus method in the Globals script library…

Looking at the ChangeStatus method in Globals, the primary thing the code does is literally change the Status field to DRAFT. However, also note how it sets the Readers field to just the [Distrobutor] role, which consists only of OCS staff.

Another important field which was looked at brielfy before but will be looked at again is DISTRIBUTED. Once a document is distributed, this field is set to 1.

Otherwise, it is 0. Notice how this field is set to 0…

Now, if the Tally Vote was already created and this ChangeStatus is called from the Tally Vote, the code has to account for it’s child ballots as well as original DIstirbution. Usiing the above-mentioned VotingDocID on the Tally Vote, the Distribution document is grabbed and the Status, Readers and dIstirbution fields are all set to Draft, [Distributor] and 0 respectively. If there are any Ballots which have been created, they are grabbed via the Responses property. The supporting document feature is legacy and not used in current DVS.

That summarized the basic code and functions on the DIstirbution form. Now, let’s take a look at the Tally Vote form. After “Create Tally Vote” is selected by the user, a new document with the Tally Vote form is created and shows up in the Working view, along with it’s Distribution document. It is intended to streamline this process but OCS users have been trained and adjusted to proceed in this manner. The user then opens the Tally Vote form to continue the path towards distribution…

While in DRAFT status, the first button to examine is “Create Ballots”. Below is the visibility formula, this button displays only if there are no response documents to the Tally Vote (i.e. no Ballots) and if the Tally Vote has been submitted from Draft.

However, the Submit button has it’s own code which will be examined which ensures it only displays if the Tally Vote ~has~ existing response documents (i.e Ballots) so the Status conditions is a redundant safeguard.

The code behind “Create Ballots” calls both the “ValidateTallyVote” and “Ballots” subroutine which are stored in Globals ~on~ the Tally Vote form (not in a script library)…

“ValidateTallyVote” is simply a series of null catches since these fields need to propogate to the Ballots..

“Ballots” calls code to create Ballots for each Commissioner listed in the Commissioners field. Another important thing in the code below is the ParentRecordNumber field. This is an integer stored in each Ballot which corresponds with the set of fields, or row, where the individual Commissioner is listed in the Tally Vote. Remember, Commissioenr_1, Commissioner_2, etc. The value in ParentRecordNumber on a partiocular ballot is the number behind the underscore in each field name on a particular row. This maps the ballot to the proper row on the Tally Vote.

ParentRecordNumber is set for each Ballot created via ActiveCommissioners loop.

Note the call to “UpdateBallot” after each Ballot is created. The primary function of this subroutine is to set the access level and Designated Voters (stored in Certifications) for each Commissioner Ballot. The Authors for each Ballot used to be set here, in UpdateBallot, but that has been moved to the QueryClose event of the Tally Vote form (to be reviewed later). Also of note here, there are Tally Votes which are distributed for Commissioners eyes only, not to be viewed by even their Designated Voters. Note how the comm_only_check variable operates in the code below, if it’s not Commissioners Only, the “dv” array is populated with the current Ballot Commissioner’s Designated Voters from Certifications…

The next portion of UpdateBallot synchronizes numerous fields from the Tally Vote to the current Ballot, including the current Commissioner and CommissionerLN value (sent from the calling Ballot subroutine, circled in blue)…

Under the last blue box, notice the call to UpdateBallots. The primary function of this routine is to synchronize the actual ballot with the current Commissioner (note how it’s inside the Forall x in doc.ActiveCommissioners loop, ie. it’s called on a per Commissioner basis) as well as parent TV fields, such as SupportingFolder and Title…

Note the “If CreateNew Then” (the CreateNew value is sent as an arg to the UpdateBallots function). This is where the tie-in between parent TV and each response Ballot is set (ballotdoc.TallyVoteID=doc.UniversalID). The doc is the parent TV, so the link is the TallyVoteID on the Ballot. There is also a similar link placed on the Ballot to the original Distribution record, which is created when a pdf email arrives in DVS (then OCS Staff sets the type as Tally Vote and clicks ‘Create Tally Vote’)…

Note the VotingDocID field = distributiondoc.UniversalID. This doesn’t really serve a functional purpose in the typical workflow of the system as the TV-Ballots tie-in is the primary mechanism. It’s more for keeping the ‘family’ together in case the entire Distribution was in error and has to be removed from DVS. This is followed by the MakeResponse (to the TV), Save, etc of the Ballot.

Back to the original Ballots function making the call to UpdateBallots. As seen above, updateBallots is called for when a Ballot is new or if the TV is updated to maintain synchronization. ..

And from Ballots, we are taken back to the original “Create Ballots” button on the TV, which made the call to Ballots…

The “Update Ballots” has the same course of action as “New Ballots”, however, notice the False arg as opposed to the True arg. This value ultimately is tied into the CreateNew variable in both the Ballots and UpdateBallots global subroutines…

Here, it should be noted about the Call LogError. This is a call to a set of undocumented and sophisticated error log librarires from IBM which are advised not to be used. As of the time of this document, it’s not producing anything as any kind of issue encountered by OCS is examined by system developer. The plan is to put a custom error log in which will write the line number and errorto a log database on the server. The system has been running smoothly at this time and any error produced in the log will still require developer troubleshooting but the log printout will facilitate the process.

The next button on the TV is “Refresh Tally”. The function here is redundant as the TV and ballots synchronization has been automated (via the Ballots/Update Ballots function calls, the QuerySave in the TV and the Vote button in the Ballot (examined later). The “Refresh Tally” button scrolls through the ballots and updates each of the “C_” fields on the TV with each Ballot…

The “End Tally” button is next. This process should be explained with some detail and how it relates to the voting deadline and closure of ballots. Essentially, they are two independent events. The voting deadline for each ballot is set by OCS in the TV…

The VoteDate and VoteTime fields are propogated and synchronized between TV and Ballots via the UpdateBallots subroutine described above…

At the end of UpdateBallot, ComputeWithForm is called on each Ballot. One of the purposes for this is that the VoteDate and VoteTime fields are consolidated into a single BallotDeadline field on each ballot. The BallotDeadline field is found on the BallotFields suform and is computed…

The BallotDeadline is then the date and time when ballots for this particular matter are closed to voting. After this point, access to the ballot by the respective Commissioners and their DVs is limited to Reader, they no longer have Author access (needed to enter votes). The mechanism for closing ballots is the “Tally Vote Cutoff” scheduled agent (set to run daily at 4:00 PM). This agent will be examined later. However, although similar, “Tally Vote Cutoff” is ~not~ related to the End Tally button on the TV. We will look at “Tally Vote Cutoff” later, right now we are still examining action buttons on the TV, thus, the “End Tally” button.

Essentially, although ballots are cutoff from voting by Commissioners and DVs, they are still open to votes being entered by OCS (who retain Author rights via [Distributor] role). With that said, the TVs remain open, even if ballots are shut-off, until OCS uses the “End Tally” button.

The code below sets the Status on the TV to “COMPLETED”, sets the document collection of Ballots and initializes the connection to the Active Commissioners in the Certifications database…

The code then scrolls through each Ballot, sets the status of each Ballot to “COMPLETED” as it did with the TV, grabs the Commissioner record with current DVs from the Certifications database and perfomrs the check to see if this was distirbuyted to the “Commissioners Only” group (meaning no DVs will not even be granted Read access to these closed Ballots)…

The code then updates the Readers field on each Ballot with the current Commissioner/DVs from the Certifications database, and removes these users from the Authors field (which allows Commissioner/DV to vote), leaving only the [Distributor] role (OCS). This is the main similarity between the “Tally Vote Cutoff” agent and the “End Tally” button…

The next button on the TV is the “Create Cert” button. This allows OCS to create a Cert Profile in the Certification database, importing various fields from the TV…

The Print button is self-explanatory. Currently in Test is a new Print functionality which addresses numerous issues with printing DVS records. It has not been approved for deployment at the time of this writing but it is worth including in this paper. The action button is labeled “Print Test (OCS only)” and is cascaded with two choices, Binder or Center. The code within each choice is essentially the same, a new document is created (printdoc), all items from the open TV (this is also done for the Distribution form for Informational and Meeting document types) are copied to printdoc, the Form field is set to a formatted Print form, and printdoc is displayed temporarily on the screen via workspace.EditDocument(False,printdoc). The uidoc is set to printdoc, the uidoc Print command is called and uidoc is Closed. The printdoc is not saved and the entire sequence is seamless in the interface. Here is the main portion of the Print- Binder option…

Note the printdoc.Form values. Note how the current Form for the currently opened record (assigned to form_name) is prepended to either “SensitiveP_binder”, “P_binder” or “P_Binder”. There are four Binder print friendly forms in DVS :

DistributionP_Binder

TallyVoteP_Binder

BallotP_Binder

BallotSensitiveP_Binder

So the code above creates the printdoc and assigns the Form to one of these values, which is then displayed in the uidoc and printed. Likewise, the “Print Test (OCS only)”…Center option uses the same code but sets the printdoc.Form to one of the four Print forms:

DistributionP_Center

TallyVoteP_Center

BallotP_Center

BallotSensitiveP_Center

Essentially, the printdoc is a temp record and is never saved.

As with the Distribution form, the TV form also has a “Submit” button. The primary purpose is to move the TV from Working View to the Distribution Center.

The code changes the Status field value on the TV from “Draft” to “COMPLETED” and calls the (Update Distribution Individuals Access List) agent to ensure any Distribution Member(s) are listed in the DVS_Individuals group in the FEC Directory.

This concludes the analysis of the action buttons on the TV. Now, the QuerySave and PostSave events on the TV will be examined. The responsibility of the code in QuerySave is to synchronize and send back key field values in the TV to the original Distribution record. As mentioned before, once the TV is created, the link back to the original Distribution record doesn’t mean a lot, however, the data link and synchronization is maintained via the VotingDocID field…

The PostSave event in the TV form works much like the Ballots and UpdateBallots subroutines described above. The primary function of the code in PostSave is to propagate the just saved TV fields to the response Ballot documents. This keeps everything synchronized. The first part of the code ensures the SupportingFolder field is sent down to the Ballots…

We will examine the SupportingFolder.