src/sbbs3 postmsg.cpp 1.131 1.132
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv26315

Modified Files:
postmsg.cpp
Log Message:
Don't try to signal an empty semaphore path if the netmail_sem is blank.


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

src/sbbs3 postmsg.cpp 1.132 1.133
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv27907

Modified Files:
postmsg.cpp
Log Message:
Include a replied-to message's to field to be selected in the post-to history (arrow-up to choose strings from history).


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/97bade44ebad5b431485e93c
Modified Files:
src/sbbs3/postmsg.cpp
Log Message:
Notify local recipients of locally-posted messages addressed to them.

While SBBSecho would notify local users of imported messages addressed to
them (both EchoMail and NetMail) and QWK-imported messages recently gained
the ability to notify local recipients of messages addressed to them, other methods of posting messages (e.g. just using the normal terminal server
method, e.g. the 'P' command) or using any JavaScript (e.g. web) methods of posting messages lacked recipient notifications. So that's now fixed.
And for JavaScript-saved local email messages too. I don't *think* this will result in any duplicate notifications of received messages, but let me know
if you see excess/duplicate notifications.
Anonymously posted messages are excluded.
Messages posted to yourself are excluded (who does that?).

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/f4ac7f3920abba7d3c717e3d
Modified Files:
src/sbbs3/postmsg.cpp
Log Message:
Resolve a gcc warning about signedness.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/c8193766c6b75abb18a2c257
Modified Files:
src/sbbs3/postmsg.cpp
Log Message:
Fix savemsg() bug introduced in 97bade44eb (Sep-30), returning false failure

'i' is the return value of savemg(), used to determine success or failure
(and what kind of failure) - so we can't use that for the usernumber of
the recipient.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/sbbs/sbbs/-/commit/a852cced25cbf1285825942f
Modified Files:
src/sbbs3/postmsg.cpp
Log Message:
Reduce unnecessary posted-to username searches. Auto-UTF8 in savemsg().

When posting to "All" or replying to a message that was posted by networked (not local) user, don't attempt to search for that username in the local user base to inform them of the posted message to them.

savemsg() is the underlying C function for saving a new message (mail or post) to a message base from several places, including JS modules. If there was no "charset" specified in the passed message header, check to see if the message body text is non-ASCII but valid UTF-8, and if it is, set the FIDO_CHARSET header field to the appropriate UTF-8 charset identifier string. This would *also* address Issue #177 reported by Michael J. Ryan. It's possible, but unlikely, that a message text would contain valid CP437 that *also* happened to be valid UTF-8. If that does happen to occur (e.g. in posted ANSI art?), we might want to revert this enhancement to savemsg() and leave to the caller's to detect/specify the charset, always.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/69111a8f420d212de3c0d638
Modified Files:
src/sbbs3/postmsg.cpp
Log Message:
If user doesn't modify the replied-to-msg subject, use the original subject

(which might be UTF-8 encoded). This works-around the problem that Accession reported in #synchronet with my reply to a UTF-8 encoded message using a CP437 terminal which resulted in a message body that was UTF-8 encoded but a message subject that was CP437 encoded. This mix of encodings is not supported by FTN standards.

This is just a work-around since if the user modifies the subject the result could still have the CP437 unside-down question marks (indicating non-translatable UNICODE chars) and those should be converted to UTF-8
chars when going out on FTN or being stored in the message base. So there's still a bug here somewhere that I need to look into more.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/1dde501fe8ea8dc8bea5e3d4
Modified Files:
src/sbbs3/postmsg.cpp
Log Message:
Call add_msg_id() *after* opening the message base to send notification email

notify() was creating wrongly-formated auto-generated Message-IDs:
e.g. Message-ID: <677B3F17.0.notices@vert.synchro.net>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/7ea01b60689e299a8a9dd131
Modified Files:
src/sbbs3/postmsg.cpp
Log Message:
Refactor/order the handling of reply-to-message header data

Fix CID 551210

There should not be any change in behavior here other than eliminating a potential null pointer dereference.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net