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, 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. 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 offline app on members' phones) 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: the offline 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, 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 THE TICKED VERSION (administrators only) 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. Only an administrator can see and use this list - the server itself refuses the download to anyone else, matching the rule on the website. DELETE THE TICKED VERSION 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. MEMBERS AND PASSWORD ---------------------- A separate button, MEMBERS AND PASSWORD, opens its own window for two things: changing the signed-in account's own password, and (administrators only) managing who belongs to the workspace. CHANGE MY PASSWORD is open to everyone who is signed in. The current password has to be typed again, even though it was just used to sign in - this is deliberate: it stops someone who merely finds Access already open and signed in from locking the real account owner out by picking a new password without proving they know the old one. The new password must be at least 8 characters long and is typed twice, to catch typing mistakes. Each of the three boxes has its own "Show" / "Hide" button, to check what was typed before sending it. On success, both the sign-in remembered on this computer and the live session are updated immediately, so nothing has to be signed in again afterwards. WORKSPACE MEMBERS (administrators only) lists every member of the workspace: email address, name and role. REMOVE SELECTED takes someone out of the workspace - their uploads and history stay on record, only their membership is removed; a member can never remove themselves this way, and the workspace can never be left without at least one administrator. SWITCH MEMBER / ADMIN flips the selected person's role, with the same last-administrator protection. ADD OR UPDATE A MEMBER creates a new account (or updates an existing one) for the email address typed in, with a chosen role and an optional password. Leaving the password blank has two different, sensible effects: for a brand-new account the server generates one and shows it once, and for an existing account its current password is simply left alone. The workspace has a maximum number of members, set by the site administrator; only genuinely new accounts count against it, so changing an existing member's role or password never runs into the limit. A member who is not an administrator only sees CHANGE MY PASSWORD; the member-management part of the window is replaced by a short note explaining it is for administrators. SENDING IN THE BACKGROUND, OR WAITING HERE ------------------------------------------- Buttons 1 and 3 (and the export step of button 2) ask, once the file is ready to go, how to send it: YES - in the background. 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 Utilities 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. NO - wait here. 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. CANCEL cancels the whole action - nothing is sent. The background choice is only offered when the helper program is installed (it arrives with a program update); on an installation that does not yet have it, uploads always run the "wait here" 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 run the "wait here" way; 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 Delete a queued version from the server - yes See the merge queue list - yes A member sees buttons 1, 2 and 4 present but greyed out, with a note explaining they are reserved for the administrator. 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 the site administrator has linked that Backend ID 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 send a registration request on the spot (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. REGISTERING A NEW WORKSPACE ------------------------------ When a datafile is not yet registered (see above), the explanation offers to send a request there and then. 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, and an optional message. The datafile's Backend ID is filled in automatically. Sending the request emails a confirmation link to the address typed in, valid for 48 hours; nothing else happens until that link is clicked. Clicking it is what notifies the developer - not the request itself - so a mistyped email address can never cause the developer to be contacted about a request nobody can actually complete. The developer then sets up the workspace and, outside Parish Record Keeper, lets the requester know it is ready; signing in from Server Actions afterwards then 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. THE START SCREEN LABEL ------------------------- On the main Parish Record Keeper start screen, a short line shows the server standing of the datafile currently open: GREEN - "Registered: Backend ID: <...>" - signed in, and the server confirms the workspace. YELLOW - "Backend not registered on the server ..." - the datafile's Backend ID has not been linked yet. YELLOW - "Not signed in on this computer ..." - no sign-in has been saved here for this datafile. YELLOW - "Server not reached - registration not checked ..." - a sign-in IS saved, but the server could not be reached just now; try again later, or check the internet connection. The line is hidden entirely when no datafile is open. It does not cost an extra server request: it reads the answer the automatic startup check (above) already obtained. 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 over a VPN, where the first attempt sometimes times out for reasons outside the parish's own connection - switching a VPN off, if one is in use, often cures repeated timeouts. 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, not encrypted for general safety - anyone who can already run programs as the current Windows user could recover it. Do not save a sign-in on a shared or public computer. - Deleting all workspace data on the server (button 4) 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 (button 1) keeps the six most recently archived masters; older ones are removed automatically to keep the server tidy. - The merge queue (button 6's list) only ever grows by members using button 3 - 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 (button 4). - Uploading the online search database (button 2) is the ONLY thing that updates what members' phones eventually see, and phones only receive it by refreshing themselves - see button 2 above. - 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. - Workspace requests (see "REGISTERING A NEW WORKSPACE") are visible only through the confirmation email sent to the developer; there is not yet a listing of them on the admin dashboard. TECHNICAL ----------- - Access pieces: Forms\ServerActions.txt, Forms\ServerLogin.txt, Forms\ServerMembers.txt, Forms\ServerRegisterWorkspace.txt, Modules\Module6_ServerActions.bas. - Background-upload helper: PS1_Scripts\PRK_Upload.ps1, built to Utilities\PRK_Upload.exe (no console window; reports progress and results through small files in the System folder, which Access polls; the helper never sees or stores the account password, only a one-time upload permission Access already obtained from the server). - Server piece: public_html\prk_api.php, together with the shared workspace functions in public_html\workspace_common.php - ws_install_master, ws_queue_upload, ws_delete_workspace_data, ws_add_member, ws_remove_member, ws_list_members, ws_delete_upload - the same functions the ordinary browser workspace page uses, so the two front ends can never disagree about what a given action does. - Workspace requests are recorded in the workspace_requests table and confirmed through public_html\confirmWorkspaceRequest.php, following the same email-confirmation pattern as new-user registration (registration.php / confirmEmail.php); the developer is notified only once a request reaches "confirmed". - A datafile's Backend ID is linked to a workspace by the site administrator on the admin dashboard (workspaces.BackendGUID) - normally after receiving the notification described above. - The saved sign-in lives in System\server_account.txt, one line per datafile, keyed by Backend ID.