Fixes the scrolled/selected position when the sysop has more than screen-full of xtrn program sections. As reported by mlong.

# Conflicts:
#   webv4/pages/000-mail.xjs

These are only used if you don't have a ctrl/text.dat file (it's 0-bytes in size), so I do delay committing these changes some times, nobody notices.

New @-codes: GIT_HASH and GIT_BRANCH
New JS system properties: git_hash and git_branch

To be sure these buggers are always created for every build that includes the
'all' target. Perhaps these should be creatd in build or an output dir and
maybe for all projects (not just sbbs3) - but will ponder tomorrow.

Add SFNet to init-fidonet

See merge request !63

webv4 header should show count for unread mail instead of all mail (using new...

See merge request !60

Kayz authored 4 years ago and Rob Swindell committed 4 years ago

webv4 header should show count for unread mail instead of all mail (using new user.stats.unread_mail_waiting)

Allows reporting of branch/commit that was used to build the code.

If for some reason building without 'git', you'll need these 2 files to
already exist somehow - still need to work that out (e.g. for daily
built-source archives).

Need to update the Windows build to generate these files now.

This fixes issue #194 reported by mlong.

Always use the return value of term_supports(), which correctly supports pre-logon and auto-terminal-capability-detection, rather than useron.misc for all door drop file generation.

This should resolve the issue recently discussed in #synchronet with regards to a user getting non-ANSI output from door games even when using an ANSI-capable terminal.

When forwarding a single-part MIME-encoded HTML email, the preamble (original message header info) and any user comments, need to be HTML-encoded.

Add the commonly-used "Fwd: " prefix to the default message subject, when forwarding.

This required that smb_getplaintext() no longer always-NULLify the message's text_subtype (e.g. "html"). For single-part messages, this element was getting freed and NULLed.

Add/use a new SMBLIB convenience function to add a string header field, but only if non-NULL: smb_hfield_string()

Add configurable options for email validation (length and valid chars)

See merge request !62

Since we're calling smb_getplaintext() manually here, and its not going to return the comment headers as part of the plain-text (the way smb_getmsgtxt() can), so we need to display find/display the comment headers first.

even when GETMSGTXT_PLAIN mode flag is used and the message contains a MIME-encoded plain-text portion. Obviously the GETMSGTXT_NO_HFIELDS exception still applies.

The fixed problem was when forwarding a MIME-encoded email, the forwarding information (and user comment, if supplied) could be suppressed/lost.

The new messages subject may be passed into forwardmail(). If it isn't, it'll be prompted for (defaulting to the original message subject).

Also, fix forwarding to QWKnet (look-up full-route/to-user-number).

‘%s’ directive writing up to 255 bytes into a region of size between 103 and 128
reported by Nelgin.

smb_getmsgtxt() returns any "comment" headers as part of the message body text, and has since 2003.
When I added mail->netmail (stored message) export support to SBBSecho v3, I duplicated this logic, so comment headers were added *twice* to exported netmail messages. Oops. I didn't notice until today when playing with forwarding-to-netmail (FTN).

Also noticed and fixed: any comment headers in posted messages (unlikely/uncommon) would not be exported to EchoMail messages. Use the correct smb_getmsgtxt() mode flags ("NO_TAILS" instead of "BODY_ONLY") - I know, not great names.

User number is not always relevant (e.g. could be #0) when sending
netmail, so don't show that. And the CRLF at in the Forwarded string
appears extraneous.

No longer derive the new message header from the original - too many problems. Simplified the forwarding support smblib (multiple SENDER* and RECIPIENT* header fields no longer expected/supported). Technically, the FORWARDED header field really serves no important purpose now.
A comment can be passed into forwardmail() or (if NULL), will be prompted for. There is an issue where the added comment can be obscured by the receiving mail program if the original message is a multi-part MIME message. Not sure the best solution for that. Still a WIP in that regard.

Update comments on jsonclient

See merge request !58