User Terms

1Purpose #

Three documents govern a sign-in, and this screen owns the third: C-Land's Terms of Use (accepted once per licence) and Privacy Statement come from the supplier; the User Terms are your own - the rules your firm sets for its staff, accepted by each person individually.

• One copy per LICENCE. Every document here belongs to your licence serial. A firm with several companies on one serial has exactly one copy - whichever company you are signed into, this screen opens the same document - and firms sharing a hosted installation can never see each other's terms.
• The copy is born from the template. The first time a licence's administrator opens this screen, the installation template is copied into that licence's own version-1 draft - from then on it is yours.
• Acceptance is per user : each login is asked once, at its first sign-in after a version is published. A user's licence comes from their user-serial link (or the installation's single serial).
• The acceptance table below is the record - who, when, and from which address. Nothing edits those rows.
• The copied version 1 carries [PLACEHOLDERS]; make it your own before publishing.

2How to use, step by step #

1. The version history grid at the top lists every version your licence has had, newest first - state, in-force date, section and acceptance counts, who created and who published each. Click a row to open that version; your first open creates version 1 as a draft copied from the template.
2. Fill the [PLACEHOLDERS]. The Auto-fill placeholders from settings button under the amber strip substitutes [COMPANY NAME] with your company's name and [ADMIN CONTACT] with your own mobile number (e-mail when no mobile is on your user record) - it fills the editor only, so review before saving. Anything it cannot fill you type by hand; publish refuses while any placeholder remains.
3. Edit the title, preamble and sections. Plain text: blank line = paragraph, a line starting "- " = bullet. Reorder with the arrows, remove with the cross, add with Add a section .
4. Save draft writes it - publishing publishes what is SAVED, not what is on screen.
5. Publish… opens a dialog asking two questions: the in-force-from date (blank = immediately) and whether to ask every user to accept again. From publishing, every user on this licence who has not accepted is asked at their next sign-in.
6. To change published words, open the published version and press New version from this - a draft at the next number, copied from it. While ANY draft is open, that button answers "there is already an unpublished draft": finish or delete the open one first. ONE open draft per licence, so two administrators cannot build rival copies.

3Rules and integrity #

• A published version is never edited or deleted. It is the record of what people accepted; the only way forward is a new version.
• One published version at a time - publishing retires the previous one. The database enforces this, not just the screen.
• One unpublished draft at a time , so two administrators cannot edit rival copies.
• Nobody is locked out by a missing setup. Until the script is run, no serial resolves, or no version is published, sign-ins proceed untouched.
• Auto-fill never fills a blank. If your user record has no mobile and no e-mail, [ADMIN CONTACT] stays and publish keeps refusing - silently publishing terms that tell staff to "ask " nobody would be worse than the placeholder.
• A refused action says why. Every toolbar verb answers in the banner at the top - "there is already an unpublished draft", "fill in the remaining placeholders" - rather than silently doing nothing.
• Only an Administrator saves here. The server refuses anyone else, whatever the screen shows.
• The text is plain text, never HTML - it is rendered to every user at sign-in, and markup from an editor would be an injection vector.

4If something does not work #