THE SERVER ACTIONS WINDOW ========================= Server Actions does, from inside Parish Record Keeper, everything the "workspace" page of parishrecordkeeper.com does in a browser: publish a new master datafile, replace the online search database, hand a version in for the administrator to merge, download the master, download a version someone else handed in, take in the change notes a phone sent from the field, or clear the workspace on the server. Nothing here is a separate system - it is the same server, the same workspace, the same rules, reached without opening a browser. It matters most for parishes with a slow or occasional internet connection: uploads and downloads run in genuine chunks with a visible progress bar, a chunk that fails is retried rather than losing the whole transfer, and a large master file can be sent in the background so the computer stays usable while it goes up. WHAT YOU NEED ------------- - A datafile whose Backend ID has been linked to a workspace by the site administrator (see "IF THE DATAFILE IS NOT REGISTERED" below). - A member or administrator login at parishrecordkeeper.com - the same email address and password used on the website. - An internet connection for each action; nothing here requires being online all the time. SIGNING IN ---------- The first time Server Actions is opened for a given datafile, a small "Sign in to parishrecordkeeper.com" box appears asking for the email address and password. Anyone who has no website account yet is told, in the box itself, to press CANCEL: the window behind it then offers REGISTER DATAFILE, which needs no account (see "REGISTERING A NEW WORKSPACE" below). Without that note a new parish could go on guessing at passwords for an account that was never created - the server deliberately gives the same answer for a wrong password and an unknown address, so nothing else would ever tell them. A "Show" button beside the password box reveals what was actually typed, in case of a mistake, and changes to "Hide" to mask it again. After a successful sign-in they are remembered on this computer, scrambled so they cannot be read at a glance or used on another computer, in one line of System\server_account.txt keyed to this datafile's Backend ID. The next time Server Actions is opened for the SAME datafile, it signs in by itself - nothing is asked again. A computer that works with several different datafiles remembers one sign-in per datafile, so switching datafiles does not mean typing the password again for one already used before. "USE A DIFFERENT ACCOUNT" (bottom left of the window) forgets the saved sign-in for this datafile and asks again - for example to switch from a member account to the administrator's. Server Actions also checks quietly every time Parish Record Keeper is started - see "BEING TOLD AUTOMATICALLY" below. THE TOP OF THE WINDOW ---------------------- Once signed in, the top of the window shows: the name and email address of the signed-in account; the role, ADMINISTRATOR or MEMBER of the workspace; the workspace name and its short name; the master currently on the server, its version number, size and publication date, and how many versions are waiting to be merged; and whether an online search database is set up for this workspace, and how many church files and baptism records it holds. This is refreshed after every action, so the figures are always current with what the server just did. THE SIX BUTTONS ---------------- 1 - UPLOAD A NEW MASTER (administrators only) Sends the datafile currently open in Access and makes it the new published master of the workspace. Every member who downloads the parish file afterwards gets this version. The master that was on the server before is archived, not lost (the six most recent archived masters are kept). An optional short note can be added for the other members, for example what was merged or corrected. 2 - UPLOAD THE DATABASE FOR ONLINE SEARCH (administrators only) Rebuilds the online search database (used by the search pages on parishrecordkeeper.com, and by the apps on the phones - PRK Admin and PRK Finance) from the datafile currently open. Everything currently online for this workspace is deleted first, then rebuilt. This button produces the export itself using the ordinary "export as text" facility, so nothing has to be prepared beforehand. This is also how the phones are fed: an app on a phone always takes ITS copy from the online database, never directly from a desktop. Nothing is "pushed" or sent to any phone from here. After a successful upload, the message says so and reminds that each phone still needs its own "Download / refresh offline copy" tap inside the app (see the separate "Offline app" documentation). 3 - SEND MY VERSION FOR THE ADMINISTRATOR TO MERGE (everyone) Sends the datafile currently open in Access to the workspace as the sender's OWN version. This never overwrites anything on the server: the file waits in the merge queue (the list box at the bottom of the window) until an administrator merges it into the master. An optional short note can be added describing what was worked on, to help the administrator merge it. 4 - DELETE ALL THIS WORKSPACE DATA ON THE SERVER (administrators only) The danger zone, identical to the one on the website. Removes, immediately and for good: the shared parish file and every archived master, every version members have uploaded and not yet merged, every change file the phones have sent and nobody has imported, and the whole online search database. Nothing on this computer is touched, and the workspace and its members remain - ready for a fresh upload - but the data already on the server cannot be brought back. Two safety catches, both required: a Yes/No warning naming exactly what will be removed, then a second box asking the exact short name of the workspace to be typed in full. Anything else typed there, including leaving it blank, cancels and nothing is deleted. 5 - DOWNLOAD MASTER (everyone) Replaces the datafile currently open in Access with the master held on the server. This is safe by construction and in a fixed order: 1. the master is downloaded to a temporary file and checked - its size and a cryptographic checksum must both match exactly what the server reported; 2. only once that has succeeded, the PRESENT datafile is copied to a dated backup in the DataFiles folder (never overwritten - if a backup with that name already exists, a number is added); 3. only then are the database connections closed and the datafile actually swapped in, and Parish Record Keeper reopens it and relinks automatically. If anything fails at step 1 or 2, nothing local is touched at all and the user is exactly where they started. Work already entered and not yet sent is not lost by taking the master: it is simply kept in the dated backup and can still be sent with button 3 and merged afterwards - though the tidiest order is to send it first, THEN take the master, so nothing has to be caught up later. The confirmation box says this plainly before asking to proceed. 6 - DOWNLOAD SELECTED (everyone) Downloads the version selected in the list box above the button into the DataFiles folder, ready to be merged using the ordinary sync/import screens. Nothing local is replaced or relinked - the file is simply placed on the disk. If a file of that name already exists there, a dated copy is saved instead so nothing is overwritten. The list shows every version currently waiting to be merged: file name, size, when it was handed in, by whom, and their note. "REFRESH THE LIST" re-reads it from the server on demand; it is also refreshed automatically whenever the window opens or a sign-in completes. The list, and this download, are open to EVERY member, not only the administrator (they were reserved for the administrator until August 2026). A member who has to carry on somebody else's work needs that person's version, and taking a copy changes nothing on the server. Deleting a version stays reserved for the administrator. The server applies exactly the same rule of its own accord, and the workspace page of the website was changed to match, so the two front ends cannot disagree about it. DELETE SELECTED FROM THE SERVER (administrators only) Removes the version selected in the list from the merge queue on the server - the file and its record - without touching anything on this or any other computer. This is for a version that has already been synced locally some other way (for example, downloaded and merged by hand) and no longer needs to sit here waiting. Asks for confirmation first, states plainly that this cannot be undone, and refreshes the list afterwards. CHANGE NOTES FROM THE PHONES ------------------------------ The lower half of the window belongs to the PRK Admin app on members' phones. Out in the field the app records corrections, new persons, new baptism entries and contributions as CHANGE NOTES; nothing is a real record until somebody takes them in on the computer (see the separate "Offline app" documentation). A phone can now SEND those notes straight to the parish's workspace - "Send to the parish computer" on its Changes tab - instead of exporting a file and carrying it here by WhatsApp, e-mail or cable. This list is the other end of that: what the phones have sent and nobody has taken in yet. The list shows, for each change file waiting: its name, how many notes are in it, when it was sent, by whom, the short note the sender may add ("Fr John's phone"), and how old the phone's copy of the parish data was when the notes were written. "REFRESH THE LIST" re-reads it on demand; it is also refreshed when the window opens, when a sign-in completes, and after every import. This part of the window is open to EVERY member. A change file is a handful of edits that are shown one by one and accepted or rejected by hand before anything is written - it is not a datafile that replaces what is here - so nothing is gained by reserving it for the administrator. The server applies the same rule independently. IMPORT THE SELECTED CHANGE NOTES (everyone) Fetches the chosen file into the Exports folder (never writing over one already there) and then goes through it note by note, each in its own window, to be applied or skipped by hand, with a report written beside the change file afterwards. That review is the same whichever way the file arrived, and OfflineApp.txt describes it in full. When the import has run to the end, the server is told and the file disappears from the list, so nobody imports the same edits a second time. An import that was STOPPED half way leaves the file exactly where it was: the notes not yet reached must stay reachable, and applying the ones already done a second time would simply set the same values again. In the rare case where the import finished but the server could not be told, the message says so and asks for "REMOVE FROM THE SERVER" to be used once it is certain. REMOVE FROM THE SERVER (everyone, within limits) Throws the selected change file away WITHOUT importing it - for one sent by mistake, or one whose edits have been made by hand in the meantime. The notes in it are then lost: nobody can import them any more, and the phone that sent them has already marked them as sent. It asks first and says so plainly. A member may only throw away what they sent themselves; an administrator may throw away anybody's. This is the same rule the merge queue uses, and again the server enforces it on its own. IMPORT A CHANGE FILE FROM THIS COMPUTER (everyone, no sign-in needed) The old route, and still the right one for a phone that cannot get online and for a parish with no workspace at all: a change file that arrived by WhatsApp, e-mail or cable and is now lying on this computer. It opens an ordinary file dialog and then reviews the notes exactly as above. This button needs no server, no sign-in and no workspace, so it stays usable when everything else on the window is greyed out. Because it needs nothing from the server, it is also offered on its own for a datafile Server Actions cannot open at all - one that is not registered, or whose workspace has been closed for an outstanding contribution. Those parishes are asked, after the explanation, whether they have a change file waiting on the computer, so the one thing that would still work is not left unreachable. MEMBERS AND PASSWORD ---------------------- A separate button, MEMBERS AND PASSWORD, in the footer of the window, opens its own window for two things: changing the signed-in account's own password, and (administrators only) managing who belongs to the workspace - adding and removing members, and switching somebody between MEMBER and ADMINISTRATOR. Every box and button of that window is described in MembersAndPassword.txt, which its own ? button opens. OTHER WORKSPACE FEATURES -------------------------- A third column on the right of the window, headed "Other workspace features", holds the two parts of the workspace that have nothing to do with moving datafiles up and down. Both are administrators' work, and both are described in their own files, which the small ? beside each button opens: TRANSPORT opens the parish transport booking register - journeys, pick-up areas, passengers, the waiting list and the fares - the same register the catechists work in on their phones at parishrecordkeeper.com/transport.php. See Transport.txt. REPORTS LOGINS creates and manages the shared usernames that let a treasurer or a section leader read the parish figures - in the PRK FINANCE app on their phone, or at parishrecordkeeper.com/report.php in a browser - without an account of their own. See SharedReports.txt. Neither can do anything for a datafile that is not registered, or whose workspace has been closed; both say so rather than opening. The other small ? buttons dotted about the window do the same thing for the section they stand beside - the online search database, downloading the master, importing change notes, and the MEMBERS AND PASSWORD button in the footer. REGISTER DATAFILE, in the footer, asks for a workspace for this datafile. It deliberately needs no sign-in at all - a datafile linked to nothing has nothing to sign in to - and is described under "REGISTERING A NEW WORKSPACE" below. SENDING IN THE BACKGROUND, OR WAITING HERE ------------------------------------------- This is no longer a question asked in the middle of an upload. It is a small pair of options on the window itself, headed "upload options", and it is set BEFORE pressing anything. It governs buttons 1 and 3 (and the export step of button 2): UPLOAD AS SEPARATE PROCESS (USE APP WHILE WAITING) - the default. Parish Record Keeper stays fully usable while the file goes up, and the upload carries on even if this window is closed, or the whole program is closed. Best for large files and slow connections. A small helper program (PRK_Upload.exe, in the System folder) does the actual sending; Access only hands it the file and a one-time permission to send it - the password itself never leaves Access. FREEZE APP UNTIL UPLOAD HAS FINISHED - the file is sent immediately with a visible progress bar; Parish Record Keeper cannot be used for anything else until it finishes. A CANCEL UPLOAD button appears while this is running. Simpler, and fine for a small file. The choice is not remembered between sessions: the window always opens on the background option, and it is greyed out while an upload is actually running. The pair is hidden altogether when the helper program is not installed (it arrives with a program update); on such an installation uploads always run the "freeze" way. A background upload's progress is shown in the same place on the window, and reported by the same message box, whether Server Actions is watching it live or was closed and reopened afterwards - it always reports the outcome exactly once. Only one background upload can run at a time; starting a second one while the first is still going is refused, with an explanation, rather than allowed to collide with it. Buttons 5 and 6 (downloads) always freeze the program while they run; there is no background option for downloads at the moment. BEING TOLD AUTOMATICALLY -------------------------- Every time Parish Record Keeper starts, it quietly asks the server, IF a sign-in is already saved on this computer for the datafile being opened, whether a newer master has been published since this account last took one, and (administrators only) whether any versions are waiting in the merge queue. If there is nothing to say, this happens silently and costs nothing to notice. If there is something to say, a message box states it plainly and offers to open the Server Actions window straight away. This check is deliberately built to never delay starting the program: it is skipped without an internet connection, it never asks for a password, it gives up quietly within a few seconds if the server cannot be reached, and any unexpected error is logged and ignored rather than shown. The start screen also shows a short coloured line (green or yellow) saying whether the current datafile is registered and signed in on this computer - see "THE START SCREEN LABEL" below. WHO CAN DO WHAT ----------------- Action Member Administrator ------------------------------------------------------------------ 1 Upload a new master - yes 2 Upload the online search database - yes 3 Send my version to be merged yes yes 4 Delete all workspace data on the server - yes 5 Download the master yes yes 6 Download a queued version yes yes See the merge queue list yes yes Delete a queued version from the server - yes See the change notes the phones sent yes yes Import change notes yes yes Remove change notes unimported own only anybody's Import a change file from this computer yes yes Open the transport booking register yes yes Set journeys, areas and the phone login - yes Reports logins - yes A member sees buttons 1, 2 and 4 present but greyed out, with a note explaining they are reserved for the administrator. Everything to do with change notes from the phones is every member's business, and "IMPORT A CHANGE FILE FROM THIS COMPUTER" stays usable even with nobody signed in at all. The server enforces the same rule independently of what the window shows, exactly as on the website. Changing one's own password is open to everyone; the member-management part of the MEMBERS AND PASSWORD window follows this same member/administrator split. IF THE DATAFILE IS NOT REGISTERED ------------------------------------ A datafile is identified to the server by its Backend ID (an internal value already inside the datafile). Until that Backend ID belongs to a workspace, the server has no workspace to offer, and Server Actions cannot do anything useful with it - trying to sign in explains this and offers to register it on the spot, either with an activation code (which takes effect immediately) or by sending a request (see "REGISTERING A NEW WORKSPACE" below); the Server Actions window itself does not open (or closes itself, if it was already open when this was discovered). Signing in with different credentials cannot fix this: it is a property of the DATAFILE, not of the account. Registering it links it to a workspace once, after which it works normally for every member. Since the window itself does not open, the one action on it that needs no server - importing a change file lying on this computer - is offered as a question straight after the explanation; the same happens for a workspace that has been closed for an outstanding contribution. REGISTERING A NEW WORKSPACE ------------------------------ When a datafile is not yet registered (see above), the explanation offers to register it there and then; REGISTER DATAFILE in the footer of the window opens the same form at any time. This works even with no sign-in and no website account at all - it is meant precisely for that situation - and opens its own small window asking for the parish name, the requester's name and email address. The datafile's Backend ID is filled in automatically. Before that window opens, the program asks the server whether this datafile is already registered, and says so instead of opening if it is - naming the workspace it belongs to. A Backend ID can only ever belong to one workspace, so registering it a second time is impossible, and it is better to hear that before typing a parish name and an email address than after. If that datafile is one you did not expect to be registered, it is most likely a copy of one that was registered earlier; speak to the administrator before registering anything else, because two copies of the same datafile sending to one workspace will overwrite each other. If the server cannot be reached at that moment the window opens as usual - the check is a courtesy, not a gate, and both buttons on the window check with the server again before anything is created. The window also asks WHERE THE PARISH IS, in two pairs of boxes that look like a repetition but are not. COUNTRY HANDLE and DIOCESE HANDLE are lists to choose from: pick the country, and the diocese list underneath then offers the dioceses served in that country. Those two decide which database on the server the parish's records will be kept in. COUNTRY (FULL NAME) and DIOCESE (FULL NAME) are for TYPING the real answer, whatever the lists said. All four are needed, and the typed ones matter most. The handles can only offer countries and dioceses that already have a database of their own; a parish anywhere else chooses "other" and the nearest catch-all, and its records are kept there perfectly safely. What the full names do is tell the developer that the parish exists - and once several parishes have typed the same country or the same diocese, that is what prompts him to give it a database of its own and move them across. A parish that leaves them vague is simply harder to look after later. There are TWO ways on from that window, and which one to use depends on whether the contribution has already been settled with the developer. 1. WITH AN ACTIVATION CODE - the workspace is ready at once This is the ordinary way. Once the parish has paid - by whatever means suits it: PayPal, mobile money, a bank transfer, cash handed over in person - the developer gives out an ACTIVATION CODE. It is short, looks something like XCPF-H4K5-M, and is meant to be readable over the telephone or through a WhatsApp message: it contains no letter or digit that can be confused with another, and dashes, spaces and capitals do not matter when it is typed back in. Type it into the "Activation code" box on the registration window, check the parish name and the email address, and press ACTIVATE WITH CODE. The workspace, the account that administers it and its first paid year are all created immediately. Nothing is sent to anybody for approval, and there is nothing to wait for - this works just as well when the developer is away for weeks, or somewhere without a telephone signal. The window then shows the email address to sign in with and a TEMPORARY PASSWORD. WRITE THAT PASSWORD DOWN BEFORE CLOSING THE WINDOW. It is shown this one time only; a copy is also emailed, but the email may be slow to arrive, may be filtered as spam, or may not be readable at all from a village. If it is lost, the developer has to set a new one by hand. Sign in with it at parishrecordkeeper.com and change it soon afterwards. The same email address and password also open Server Actions here on the desktop. A code works once and once only. If the email address given already has an account on the website, no new password is created and no email is sent - that account simply becomes the administrator of the new workspace as well, and signs in with the password it already uses. The window says so plainly instead of showing a blank password. If the copy of Parish Record Keeper in use is too old to have an ACTIVATE WITH CODE button, the same thing can be done from any web browser at parishrecordkeeper.com/redeemActivation.php. That page asks for the code and for the datafile's Backend ID, which is shown on this same REGISTER DATAFILE window - read it across and type it in. Everything else is identical, including the temporary password shown once. 2. BY REQUEST - when nothing has been paid yet If there is no code, press SEND REQUEST instead. This asks the developer for a workspace, and it does have to wait for him. Sending the request emails a confirmation link to the address typed in, valid for 48 hours; nothing else happens until that link is clicked. The link opens a short page that asks the requester to tick a box confirming the payment has been made and to describe it briefly - how, when, and any reference or receipt number - and only then is the request confirmed and the developer notified. Clicking the link is therefore what notifies him, not the request itself, so a mistyped email address can never cause him to be contacted about a request nobody can complete. He then sets the workspace up and lets the requester know it is ready, outside Parish Record Keeper. Signing in from Server Actions afterwards works normally. Sending another request for the same datafile while an earlier one is still unconfirmed simply replaces it with the new details and a fresh link - the old link stops working. Once a request has been confirmed, sending another for the same datafile is refused, with a reminder that one is already waiting to be set up. Sending a request costs nothing and commits the parish to nothing: no workspace exists, and nothing is asked for, until the parish has actually contributed. WHAT A WORKSPACE COSTS, AND FOR HOW LONG ------------------------------------------- What the contribution covers, the terms on offer, how renewal is counted and what happens if it is left outstanding are all set out in WorkspaceBenefits.txt, and the full terms in the Cloud Service Agreement (Documentation\CloudServiceEULA.txt, Section 12). Two things belong here, because they are properties of this window rather than of the arrangement: The CONTRIBUTION box at the top of the registration window lists the terms with their amounts, read from the server, so what is offered is always what is in force rather than whatever a particular program version was built with. Each is quoted in kwacha and in dollars, and either may be used. Pick the one the parish is actually paying for; it can still be changed later, on the page that confirms the payment. If the program cannot reach the server at that moment, the box says so instead of showing terms, and the request can still be sent: the amount is confirmed by email afterwards, and nothing is owed until the parish decides to go ahead. THE START SCREEN LABEL ------------------------- On the main Parish Record Keeper start screen, a short coloured line shows the server standing of the datafile currently open: which workspace it belongs to and how far the current contribution reaches, or else why the server could not answer - not registered, workspace closed, not signed in on this computer, or not reached just now. It costs no extra server request: it reads the answer the automatic startup check (above) already obtained, and it is hidden entirely when no datafile is open. Clicking it asks the server again. Every line it can show, and what each one means, is set out in StatusLine.txt. IF THE CONNECTION IS SLOW OR FAILS -------------------------------------- Every request to the server first tries with an ordinary timeout; if that specific attempt fails to connect at all (as opposed to the server answering with an error), it is tried once more with considerably more patience before giving up. This particularly helps with some IP addresses that may be blacklisted by our servers for reasons beyond our own control. Using a VPN or changing the VPN's IP often solves this situation. A definite answer from the server (a wrong password, a permission refused) is never retried, since asking again cannot change it. If an upload or download does not complete, nothing already published or in place on the server is changed by the failed attempt, and the local file involved is not deleted - the message explains what happened and the action can simply be tried again. NOTES FOR THE ADMINISTRATOR ------------------------------ - The password saved on this computer (see "SIGNING IN") is scrambled for THIS computer only. Do not save a sign-in on a shared or public computer. - Deleting all workspace data on the server does not touch anything on this computer, and does not remove the workspace or its members - only its content. A fresh upload can be made immediately afterwards. - Publishing a new master keeps the six most recently archived masters; older ones are removed automatically to keep the server tidy. - The merge queue only ever grows by members uploading their versions - nothing is ever silently removed from it except by an administrator publishing a new master (which marks every currently queued version as merged) or the workspace being cleared. - Uploading the online search database is the ONLY thing that updates what members' phones eventually see, and phones only receive it by refreshing themselves. - A member's temporary or changed password is shown once, in the message after ADD OR UPDATE A MEMBER; it is not stored anywhere for later retrieval, so pass it on before closing the message. - Removing a member, or changing their role, never affects anything on their own computer - only their access to the workspace on the server. - Deleting a queued version cannot be undone once done, but only removes it from the merge queue on the server - the person who sent it in still has their own copy, unaffected. - Change notes from the phones never write anything by themselves: every note is shown and accepted by hand. A note applied on this computer is written down in System\imported_changes.txt, which is what lets the review window say "ALREADY IMPORTED on ..." when a phone sends the same note again. Losing that file costs nothing but the warning. - The server recognises a change file it already holds by its contents, so a phone sending the same notes twice stores nothing twice. (A phone does not lose a note by sending it - see OfflineApp.txt.) - At most 50 change files can wait on the server per workspace, so a phone stuck in a loop cannot fill the disk. Importing them, or removing them, clears the way again. - A change file that was imported leaves its row on the server as the record of who sent it and who took it in; one thrown away unimported leaves no trace, exactly like a deleted queued version. - Workspace requests and activation codes (see "REGISTERING A NEW WORKSPACE") are listed on the admin dashboard, where a confirmed request is turned into a workspace with one click and codes can be issued, watched and withdrawn.