Added chat-settings to SCFG->System->New User Values->Toggle Options
Added new menu: SCFG->System->New User Values->QWK Packet Settings

Moved SCFG->System->New User Values->Question Toggles to:
      SCFG->System->New User Prompts...

This fixes issue #11

This includes a new JS bbs method: bbs.chat_sec()

And the old command shells written in Baja now call the PCMS
chat_section function, as they used to, rather than hard-coding the
name of the module to execute.

Most sysops didn't know it, but if exec/feedback.* existed, it would be
executed just before any user sent an email to the sysop (user #1),
excluding new user validation requests:
- make this module name configurable and loadable from mods
- support JS module here (exit(1) to abort the feedback)
- invoke for email being sent to *any* sysop (not just user #1)
- don't invoke the module when sending *from* a sysop account

This fixes issue #16

You want to replace the built-in batch file transfer menu with your own
loadable module across all command shells? Now you can.

Configured in SCFG->System->Loadable Modules:
Scan Dirs:      User scans one or more directories for (e.g. new) files
List Files:     User lists files within a file directory
View File Info: User views detailed information on files in a directory

This addresses/fixes feature request #521 for Nightfox

Will need to document the mode argument bit values on the wiki, but
it's the usual suspects: FL_* for scandirs and listfiles and FI_* for
fileinfo. The scandirs_mod will be passed an extra bool (0/1) arg that
indicates whether or not the user is scanning *all* directories.

Test results would be welcome

Also modifying the existing (sample) userlist.js to mimic the hard-coded
sbbs_t::userlist() function (from str.cpp), suitable as a user list
module. Also added sort-by-laston-date functionality to this module,
thus fixing issue #518.

Previously, many/most loadable modules were limited to just 8 chars,
so while technically you could include a command-line option with a
very short module name, now all modules can be configured with full
(up to 63 char) command-lines.

Missing part of yesterday's commit, whoops

modem init strings, alt file paths, PostLink name/number, node-specific command-lines, etc., many of these haven't been used since SBBS v2.

The validation user (required new user feedback user number) and error notification/level settings don't make sense under node settings in today's world where all nodes typically run on the same system and serve the same BBS.

Moved from SCFG->Nodes->... Advanced Options to (new sub-menu) SCFG->System->Notifications. Likewise, these 3 settings (valuser, erruser, errlevel) were moved from node*/node.ini to ctrl/main.ini.

If you're already running v3.20a, then you'll want to make sure you set these in SCFG->System->Notifications how you prefer them as the migration (now handled in upgrade_to_v320.js) won't have been done for you automatically. The default is no-new-user-feedback required and no-error-notification user set.

Added a prompt to the SCFG setup wizard to prompt for this setting since it still is a FAQ.

Other cosmetic changes to SCFG help and setup wizard.

Resolve the QWKnet hub 'days' key in msgs.ini being written as -1

The default value is the same as the previously hard-coded value: 15 minutes.

Increase this value to prompt the sysop for the system password less frequently, decrease for more frequent.

This fixes issue #407.

For Viewable, Testable, Compressible file types and download events,
the file extension is no longer limited to 3 characters. 15 characters
seemed like "enough".

Similarly, a user's temp/QWK file type preference is also extended from
3 to 15 characters.

This fixes issue #486, but file types such as *.tar.gz (2 dots in the extension)
are still an issue and will be addressed next.

<server>/state is now published directly to the <sever> topic level (the "state" topic goes away).

Moved <bbs-id>/node# topics to <bbs-id>/nodes/# (allows better wild-card subscription per MQTT standards).
Publishing total node count to <bbs-id>/nodes rather than <bbs-id>/node_count

Introduced "publish verbosity" control (defaults to "High") - if you want nice human readable (and sometimes redundant) topic messages, leave this set to "High". To reduce traffic, set to "Low". It's expected that purpose-built Synchronet/MQTT clients should work equally-well with either setting, but when using generic MQTT clients/browser, "high" verbosity is nice. The human-readable node status is only published when "high" verbosity is enabled.

Publishing the BBS name to the <bbs-id> topic, the instance hostname (as configured in sbbs.ini) to the <host> topic. Makes the hierarchy much more clear when using an MQTT browser like MQTT Explorer.

Previously, many servers and services didn't support login by real name
(e.g. issue #469) even if the sysop had that option enabled in SCFG.

Move login control settings from node.ini to system (main.ini -> login)

The 3 node toggle options:
- Allow Login by User Number
- Allow Login by Real Name
- Always Prompt for Password

... have been now moved from SCFG->Nodes->Node x->Toggle Options to
SCFG-System->Toggle Options.

If you upgraded to v3.20a before now, you'll want to double-check these
settings to make sure they're how you want them set. New upgraders that run
upgrade_to_v320.js (e.g. via 'jsexec update') will get these settings migrated
automatically.

Added some error detection/logging to upgrade_to_v320.js when failing to open
.cnf files.

Constified some more user/login related function args and return types.

(minimum severity of log messages that will be published via MQTT)

publish QOS still defaults to 0 (for now at least), while
subscribe QOS defaults to 2.

Default MQTT version is 5
Default username, password are block. Up to 255 chars each.

Requires libmosquitto (e.g. install mosquitto-dev pkg) and set
in ctrl/main.ini:
[mqtt]
Enabled=true
broker_addr=127.0.0.1
broker_port=1883
qos=0
keepalive=10

Next up: Windows support

This allows the sysop to configure the settings to be used for newly-created and auto-added directories without requiring any "template" directory to be configured. The "template" directory concept goes away (so in this way, File libs/dirs are now different from Message groups/subs in how bulk configuration is done).

The Lib->Clone Options menu option was moved to Lib->Directory Defaults->Clone Settings and no longer uses the first sub or the template sub but rather the configured directory defaults to be cloned into all dirs in the lib.

I decided to make the dir_defaults their own sections in file.ini rather than combining with all the other lib settings (and deconflicting key names such as "sort" and "settings"). This also allowed me to use the same cfg read/write functions for those directory settings and lib's directory default settings.

Upload and Download ARS must be matched *and* the directory's upload and download ARS.

Operator and Exemption ARS must be matched *or* the directory's operator and exemption ARS.

Just to help resolve some warnings in scfg*.c

By default, each file transfer directory's internal code suffix is
used as the source of the sub-directory of the virtual path used
to represent a file area in the FTP and Web servers. Now, a sysop
can change that source to either each directory's short name or
long name, if they prefer.

For MRO, because he asked (on DOVE-Net).

For the following log files:
  hungup.log
  error.log
  crash.log
  hack.log
  spam.log
  guru.log

... they can be limited in size, in bytes, by the sysop, along with a maximum retention limit (number of *.#.log files). Configured in SCFG->System->Advanced.

By default, the limit and keep numbers are 0, so "unlimited" (same behavior as before). Once sufficiently tested, I'll change the default in a stock main.cnf file to use a sensible limit (e.g. 10 log files of 10MB each, something like that).

Credits and daily free credits are accurate to the byte up to (a maximum) of 18446744073709551615 (that's 18 Exbibytes - 1).

User's upload and download byte stats are now similarly extended in maximum range, but the accuracy is only "to the byte" for values less than 10,000,000,000. Beyond that value, the accuracy declines, but is generally pretty damn accurate (to 4 decimal places beyond the nearest multiple of a power of 1024), so I don't expect that to be an issue. This method of storing upload/download byte stats allowed me to use the same 10-character user record fields in the user.dat file.

As a side-effect of this enhancements:
* User and file credit values are now expressed in multiples of powers of 1024 (e.g. 4.0G rather than 4,294,967,296).
* Free credits per day per security level has now been extended from 32 to 64-bits (to accommodate values >= 4GB).
* adjustuserrec() now longer takes the record length since we can easily determine that automatically and don't need more "sources of truth" that can be out-of-sync (e.g. the U_CDT field length going from 10 to 20 chars with this change).
* setting the stage for locale-dependent thousands-separators (e.g. space instead of comma) - currently still hard-coded to comma
* more/better support for files > 4GB in size (e.g. in the batch download queue)
* user_t ulong fields changed to either uint32_t or uint64_t - I didn't realize how many long/ulong's remained in the code (which are sometmies 32-bit, sometimes 64-bit) - ugh
* Steve's ultoac() function renamed to u32toac() and created a C++ wrapper that still uses the old name, for homage

It bothered Deuce having a web server setting in scfg_t/SCFG->File Options, so I moved this setting to [web_]startup_t and the sbbs.ini file.

The downside is that file_area.web_file_prefix is no longer available to JS environments outside of the web server and terminal server, but meh, probably not going to use it elsewhere anyway? I can imagine use cases for JSexec scripts to want to generate URLs to filebase files. If that ends up being a need, they'll have to find and parse the "right" sbbs.ini file to determine the vpath prefix. 

This change is just for internal consistency and convenience right now: the lib_t.vdir is a "sanitized" copy of the lib's short name (spaces are converted to dots or underscores based on the logic that the FTP server used in dotname()) and the dir_t.vdir is just a pointer to the dir's code_suffix. No other permutations are made (e.g. lower-casing the strings). Although the virtual directory names of libraries will now appear in mixed case in the FTP server (previously, they were all lowercase), the directory names are actually treated case-insensitively, so it should not make any difference. If forced-lowercase is preferred for some reason, please speak up.

This change leads the way to eventually, possibly, making these virtual path elements sysop-configurable. For now, it's just better to have a *copy* of the lib's short name that is appropriately modified to make a suitable directory name and have that vpath element available globally (to all servers and services) in a consistent manner.

So Nelgin asked (about filebase access via http), what if the library short name has a space in it? The answer now is, the spaces are replaced with a '.' or '_' (if there's already dots in the name).

By setting SCFG->File Options->Web File Virtual Path Prefix to something (e.g. "/files/"), all HTTP or HTTPS requests to the Synchronet Web Server with request paths beginning with this prefix will be interpreted as filebase access requests (with full access control enforcement). This is configured here (in SCFG) rather than, say, the [web] section of sbbs.ini, because I have plans for the terminal server to use this prefix to generate Web-URLs for files to display or email to users.

Currently, only requests to *files* (for download) are supported (no index generation, file information, etc. and definitely no upload support). Full access control (using HTTP auth, not cookies) is used for libraries and directories with controlled access. Credits are deducted and awarded and uploaders are notified of downloads, as one would expect. Requests to any dynamic-web-content files (e.g. .SSJS, .XJS, etc.) will be treated as static file download requests (no script will be executed).

I'm reusing the same virtual path parsing logic from the FTP server (moved to the userdat lib), so the virtual path to a file for download would be, for example, http://yourdomain/files/lib/dir-code/filename.ext

The main motivation for this feature is: FTP-links in email and web pages are just not useful to many users these days and I don't think that sysops should have to rely on a SSJS web UI (e.g. ecWebv4, cool as it is), to provide web-access to the filebases. Using this feature, you can share simpler/shorter web links to your files that will be more enduring.

Default to 64 characters. Maximum value is 65535 characters, but filenames larger than 64 characters may be problematic (e.g. searching for them, displaying them, security concerns), so only increase with caution. Shorter values are fine, but 0 will just revert back to the default.

sbbsctrl.exe is built with Borland C++ still which only has a 32-bit time_t, so to keep the scfg_t definition compatible between MSVC and Borland builds, use time32_t (32-bit time_t) values only.

This fixes the reported sbbsctrl.exe error:
Error loading configuration
cfg->size (23944) != sizeof(scfg_t) (23952)

Introduced in commit b76b5318.
Reported via DOVE-Net by  Daryl Stout (TBOLT), confirmed by Nightfox (DIGDIST).

With the old method, it was possible for a certificate to remain used
eternally, and letsyncrypt.js can change it relatively often.

Up to 40 characters can be configured by the sysop for gender options.
The default choice/configuration is now: "M/F/X" (not just "M/F")
New @-code: GENDERS
text.dat EnterYourSex -> EnterYourGender

Closes enhancement request #291 by Ragnarok

Per FMail.txt:
Area name
          This is the name of the conference. It can be up to 50
          characters long. This name is often referred to as the
          area tag.

I did not locate a FidoNet spec to contradict that and support a 35 character maximum area tag length. I think Mystic also has a 50 character area tag limit. So 50 character area tags are fine I guess.

So up to 50 characters are now supported in SBBSecho and SCFG for area tags (for message and file echoes). The exception is the (new to 3.19) optional area tag stored in msgs.cnf/file.cnf is limited to 40 characters due to reserved space limitations. If you need a tag stored per sub (most sysops do not) and it needs to be longer than 40 chars, use the newsgroup name instead (limited to 63 chars).

Changed at the request of Keyop via IRC.

This module (name configurable in SCFG->System->Loadable Modules) replaces the old hard-coded temp/archive file menu in v3.18 and earlier, going all the way back to v1a. Good-bye to yet more old and crufty Synchronet C source code. :-/

Change the "Pre Xtrn Prog" and "Post Xtrn Prop" menu option in SCFG->System->Loadable Modules to just "Pre Xtrn" and "Post Xtrn". The help text had the wrong names anyway (now fixed).
Save the menu lightbar position in the "Loadable Modules" SCFG menu.

According to  Lupine Furmen (FURFOL):
It says in the help that the field is used for both the Newsgroup name AND the
Fido Echo-tag.

These really should be 2 different fields.

Now, the echo/area tag is usually configured in the area file (areas.bbs) and so does not need to match *any* string configured in SCFG. But since an area file *can* be generated from SCFG (Export Areas option) and its possible to use SBBSecho withOUT an area file at all, then it's possible someone would like to have their FidoNet-style area tags configured different from any other strings related to a sub-board (e.g. newsgroup name) - why? I'm not clear, but there it is: another string that  a sysop can set (or not).

Since I'd recently added an area tag field per directory for use by hatchit.js, this does create some logical symmetry. And there were enough free bytes per-sub in the msgs.cnf, so why not.

This won't impact Synchronet as it has a separate signal handling
thread, but we still need to behave properly for processes that
don't.  I'm also saying that ENOMEM does not indicate a disconnection,
though it may be better to pretend it was disconnected...

Jump the time forward (in 24-hour chunks) to find the next date/time the event will run rather than just adding 24-hours and assuming it's an event that runs every day (of the week or month) at a specific time.

Also, expose the next-run-date/time for an event as a new `next_run` property for `xtrn_area.event[]` (in `time_t` format) for easier debugging of these kinds of issues.
Also expose the error log level as a new property: `error_level` while we're here.