Source: SPITFIRE.DOCEdition: searchable Web reading editionPresentation: historical wording retained
13.0 - SPECIAL COMMANDS FOR SYSOP STATUS
----------------------------------------
Definition of Sysop Status
--------------------------
A caller with Sysop Status is defined as any caller that has a
security level equal to or greater than the Sysop security level set
using SPITFIRE's ALT+Z configuration window at the "Ready..." prompt.
The Message section has a few "Special Commands" for callers with
Sysop Status.
When a Message Conference is configured to allow the caller the
ability to delete messages, it is important to note that only the
sender and receiver can delete messages, with the exception of callers
with Sysop Status. Any caller with Sysop status can read, delete, and
un-delete any message.
Any caller with Sysop Status may enter messages into all Message
Conferences even though the caller's security may not be equal to
or greater than the Message Entry Security configured by the Sysop.
The <P>rivate command is a toggle that is available to callers
with Sysop security and can be used to toggle a non-public message to
public or a public message to non-public.
The <C>opy command will allow a caller with Sysop security to
move a message to another Message Conference or copy a message within
the same conference and forward the message to another caller other
than the original recipient of the message.
Last in the message arena is the <U>ndelete command. Anyone with
Sysop Status will automatically be able to read all the messages in
the message base, even if the message has been deleted. Those who see
a message which has been marked for deletion may undelete it by using
this command. Callers are not able to read deleted messages unless
their access level is equal to or greater than Sysop Status.
When a message is Undeleted, changed from Non-public to Public or
changed from Public to Non-public, the message is re-displayed so
the change can be verified. When a message is changed from Non-public
to Public, an option is given which allows the message to be addressed
to "All Callers".
In the File Area, if a caller with Sysop Status attempts to upload
a file that already exists, that caller is given the opportunity to
overwrite the file. The caller is warned that the file already exists
and is given the option to overwrite it. SPITFIRE does not allow any
callers without Sysop Status this privilege.
13.1 - SPECIAL COMMANDS FOR SYSOP
---------------------------------
The Sysop is determined within the ALT+Z configuration window.
The name entered as Sysop Caller Name is used by SPITFIRE to
determine the name of the Sysop. Messages left using the <C>omment
to Sysop feature from the Main Menu feature are displayed to the
person logging on under this name.
The Sysop has some features available to them that no other callers
have, regardless of the caller's security. When selecting the option
to read messages, if recognized as the Sysop, the caller is prompted as
to whether he/she wishes to preview messages. This feature allows the
Sysop to read messages without the messages being marked as having been
received. A handy use for this feature may be when Sysops don't have
time to respond to all their messages. They can still read messages
and respond to those they choose. Callers will not see that the Sysop
has received the message and feel slighted by the fact that there is
no response. Sysops can re-read messages later and respond when they
have more time to devote to responding to messages. Also, those with
Sysop-Level security have an "unlimited" number of daily node chats of
"unlimited" duration.
The Sysop of the BBS can enter a message to SFCALLER and SPITFIRE
handles this as a message which is addressed to every caller on the
board. So, when a caller logs on and performs a message scan, SPITFIRE
will consider all messages addressed to SFCALLER as a message addressed
to the current caller.
Additionally, the Sysop of the BBS can enter a message addressed to
SFCALLER<x>, where <x> is equal to a valid security level on the BBS.
SPITFIRE will handle this as a message addressed to every caller of
the board with the specified security level. In other words, when a
caller with a security level of 10 logs on and performs a message scan,
SPITFIRE will consider any messages addressed to SFCALLER10 as a
message addressed to the current caller.
It is important to know how SPITFIRE handles the SFCALLER and the
SFCALLER<x> messages entered by the Sysop. For obvious reasons, the
caller is not allowed to delete any message received by them and
which is addressed to SFCALLER or SFCALLER<x>. Secondly, the date
the caller last logged on to the BBS is compared to the date of the
SFCALLER/SFCALLER<x> message to determine if the message should be
displayed to the caller. If the date of the message is more
recent than the date the caller last logged on, the message will
be reported as an unreceived message to the caller when SPITFIRE
performs a message scan.
When using this feature, the Sysop will need to assume some
responsibility in regard to deletion of the message. Only the Sysop
can mark a SFCALLER/SFCALLER<x> message for deletion. If such a
message is entered in a conference that allows unreceived messages to
be purged, it will purge when the message pack is performed and the
message is older than the configured Purge Msgs Older Than value for
that message conference. However, if the SFCALLER/SFCALLER<x>
message is saved to a message conference that is configured to not
purge unreceived messages, the Sysop must mark the message for
deletion or it will never purge.
SFCALLER/SFCALLER<x> MESSAGE TIP! The ability to enter a message
that will never purge can actually work to the Sysop's advantage.
For instance, if the Sysop would like to keep certain messages on
their BBS indefinitely the SFCALLER messages provide the tools by
which to accomplish this. Simply enter a SFCALLER/SFCALLER<x>
message into a message conference that is configured to not allow
unreceived messages to be purged. One example that comes to mind, is
a general message to all callers that explains how to disable call
waiting prior to calling the BBS.