RFE: Modification time-dependent delay of email alerts
(1) By Warren Young (wyoung) on 2020-03-25 01:48:07 [source]
Migrating a SQLite forum post subthread:
The delay between a change hitting the Fossil blockchain and an email alert going out for it to subscribed users is complicated, ranging from approximately immediately to a minute later in the recommended configuration, though potentially longer by local configuration.
The key problem is that the blockchain change time is under control of the user and the alert scheduling is independent of this, dependent in part upon the server's system clock and its cron implementation.
This causes a particularly annoying problem with forum posts, since it means you may or may not have time to make a quick edit to the post and get the new version sent out to subscribers instead of having both versions go out on different "ticks" of the alert sending clock.
I think there's a simple fix to this: delay alerts for 5 minutes past the last change in the case of tickets, wiki, and forum posts. (I am purposefully excluding the delay for announcements and commits.) That means if you post something and see an error only after it's committed to the block chain, you have 5 minutes from the "Submit" time to fix it if you want your new version to go out via email instead of the original version.
If you sit there for 6 minutes fiddling with the text, the first alert will go out anyway, causing a near-duplicate once you post your new version, but Fossil can't reasonably lock things up forever.
Any requirement to have periodic feedback about edit status from the client side will probably be rejected, since that makes JavaScript support a hard requirement, something we generally avoid. JS is for progressive enhancement, not for essential functionality.
(2.1) Originally by anonymous with edits by Stephan Beal (stephan) on 2020-03-25 01:58:31 from 2.0 in reply to 1 [link] [source]
If you sit there for 6 minutes fiddling with the text, the first alert will go out anyway,
Perhaps using the Preview option could/should reset the timer, giving the user more leeway.
In JS jargon this type of delay is called "debouncing," and is often used to avoid submitting AJAX requests for every keystroke (e.g. when typing in a progressive search field). That feature has been put through the paces in JS, and perhaps some of the JS implementations for this can provide useful ideas for how to add it to fossil.
(edit: this was stephan - the browser said i was logged in, then posted anonymously - haven't seen that happen in many months.)
(4) By Richard Hipp (drh) on 2020-03-25 02:25:49 in reply to 2.1 [link] [source]
i was logged in, then posted anonymously
That has happened to me too. We need to chase that bug to ground and fix it.
(9) By Warren Young (wyoung) on 2020-03-25 03:18:41 in reply to 4 [link] [source]
i was logged in, then posted anonymously
That has happened to me too. We need to chase that bug to ground and fix it.
I'm pretty sure I diagnosed the cause for it, months back. One case of it, at the least.
It seems to be this particular case, as well, since Stephan's last-logged IP address is different from the one this Fossil instance saw him at two days ago.
(10) By Stephan Beal (stephan) on 2020-03-25 03:29:17 in reply to 9 [link] [source]
In this day of mobile devices which can change networks several times in the space of a train/plane commute, associating logins with IPs/netmasks sounds like an increasingly fragile implementation strategy. My household IP is subject to change every day when the router is forced to reconnect early each morning (that's still a thing some ISPs do to help prohibit subscribers from running full-time internet-facing servers).
(15) By ddevienne on 2020-03-27 10:42:22 in reply to 4 [link] [source]
What will happen to all the posts incorrectly attributed to anonymous?
Are they going to stay that way forever, w/o possibility to be correctly re-attributed?
(16) By Stephan Beal (stephan) on 2020-03-27 12:30:39 in reply to 15 [link] [source]
There is no technically reliable way to determine their initial ownership - all we have is one person's word that they wrote the original. (Granted, that's almost certainly sufficient for our purposes, but "it's the principle of the thing.")
The user's name is baked into the forum record. It would hypothetically be possible to apply an amendment tag, as we do with commits, but that seems overkill to me, given how seldom it happens, in particular if we can eliminate this problem quickly.
Warren's IP hypothesis sounds more reasonable to me than any i've come up with, and i'd personally be all for eliminating any use of IPs in user validation (instead just using a long random hex/base64/etc. code), but any change in that regard has potential security implications which would require a sign-off from Richard.
(3) By Richard Hipp (drh) on 2020-03-25 02:24:39 in reply to 1 [link] [source]
One problem with that approach is that it introduces a 6-minute latency in the response. The posted question reaches the people with answers after a 6-minute delay, which means that the answers are delayed by at least 6 minutes.
As an alternative, what if we just never send Edit notifications unless they occurs more than one hour after the original post? Do you really need an email telling you that somebody fixed a typo?
We could also compute a delta between the between the original text and the edited text and use the size of that delta as a proxy for the entropy change, and only send an alert if the change exceeds some threshold. Maybe some function that involves edit time and delta size could be used.
I'm thinking that just not reporting edits that occur within one hour of the original post will be adequate, though. Trying to add an change entrophy threshold is just over-complicating things.
(5) By Stephan Beal (stephan) on 2020-03-25 02:33:30 in reply to 3 [link] [source]
I'm thinking that just not reporting edits that occur within one hour of the original post will be adequate, though.
That sounds like a completely reasonable compromise. An entropy check might be an interesting problem to attack on a rainy day, but simply not sending updates for the first hour or so probably resolves 99% of objections to repeated updates.
The anonymous posting things has not hit me in a good 6 months or so, and i thought it had simply resolved itself through code evolution.
(6) By Stephan Beal (stephan) on 2020-03-25 02:36:39 in reply to 5 [link] [source]
PS: admin edits to some else's post (but not their own) should probably be excepted from a delay.
(7.1) By Richard Hipp (drh) on 2020-03-25 02:56:02 edited from 7.0 in reply to 6 [link] [source]
Are you sure? It is common for me to approve a new anonymous post, then immediately turn around and edit it because the poster has never used Markdown before and doesn't know how to format it reasonably. Sometimes my edit is merely to change the Markup Style from "Markdown" to "Plain text". Do we really want two emails going out for that?
(8) By Stephan Beal (stephan) on 2020-03-25 02:58:28 in reply to 7.1 [link] [source]
Probably not. Perhaps admin edits instead need a checkbox indicating whether or not to send an update? Maybe it's an imaginary problem - still working on today's first coffee.
(11) By sean (jungleboogie) on 2020-03-26 05:20:24 in reply to 1 [link] [source]
Not exactly sure what RFE is, but guessing - is it request for enhancement?
I do like the idea of having a delay, either the 6 minutes or the full hour like drh mentioned. Reddit allows you to edit a post up to a minute before it shows as edited. I'd oppose anything less than 6 minutes.
(12.1) By Richard Hipp (drh) on 2020-03-26 20:18:20 edited from 12.0 in reply to 1 [link] [source]
Experimental Enhancement Now On-Line
Fossil has been modified (on trunk!) so that there is a new subscription parameter specifically to receive alerts for edited posts. So now, each subscriber selects separately:
- Notifications for new forum posts
- Notifications for edits to existing posts
You can select neither, either, or both. There used to be only one option for "forum posts" and you if selected that option you got notification of both initial posts and edits to that post.
Action Required On Your Part
The settings for existing subscribers only have "Forum Posts" enabled. The new "Forum edits" setting is disabled by default. If you want to get an email every time an forum posting is edited, you'll need to adjust your subscription settings.
If you are reading this posting via email, there will be a link at the bottom of the email that you can visit to adjust your subscriber settings.
These changes are experimental
Even though they are on trunk, I'm willing to back them out or modify them if there are better ideas. But you will need to speak up and advocate your better idea.
(13) By Richard Hipp (drh) on 2020-03-26 20:20:02 in reply to 12.1 [link] [source]
I made an innocuous change to the previous post. Since no subscribers (other than me) have yet signed up to receive Forum Edit notifications, none of you should have received an email with my edit.
If you did receive an email reporting the edit, that is a bug. Please report it. Thanks.
(14) By Kevin (KevinYouren) on 2020-03-26 21:25:09 in reply to 12.1 [link] [source]
Recompiled Fossil from trunk.
Signed up.
Created this message in my clone of Fossil Forum.
Thu 26 Mar 21:18:37 UTC 2020 Fri 27 Mar 08:18:37 AEDT 2020
Now continuing my edits.
So, I'm using my clone for "Draft" -
Then edited, etc.
Thu 26 Mar 21:23:41 UTC 2020 Fri 27 Mar 08:23:41 AEDT 2020
regs,
Kev