http://www.perlmonks.org?node_id=1076201

This is not a feature request!

... more a meditation. :)

If we'd supply a unique id for each comment session, could this be used to reject or warn about accidental reposts?

I.e. after clicking "comment" a hidden field would contain something composed from parent-node-id + user-id + timestamp + random number and passed thru the "preview" and "create" stages.

After first posting this ID could be "disabled". Either by storing in the DB-table holding the final post or by caching it for x hours.

A considerable part of NTCs deals with such accidental duplicates and even experienced monks regularly fall into the trap (especially when using mobile clients)

Am I missing something?

If this was already discussed before please point me to the discussion.

Cheers Rolf

( addicted to the Perl Programming Language)

Replies are listed 'Best First'.
Re: Avoiding accidential reposts
by toolic (Bishop) on Feb 26, 2014 at 00:00 UTC
Re: Avoiding accidential reposts
by Anonymous Monk on Feb 26, 2014 at 02:55 UTC

    If we'd supply a unique id for each comment session, could this be used to reject or warn about accidental reposts?

    Sure, a nonce ( https://www.owasp.org/index.php/Session_Management#Page_and_Form_Tokens , Cryptographic nonce, Plack::Middleware::CSRFBlock ) should prevent double posting where the content isn't identical (identical duplicates should already be rejected)

    I'm sure tye gods already thought of it when adding "prevent identical duplicates" feature and rejected it for some reason :)

    ... disabled ... Am I missing something?

    so to prevent duplicates, a new database table/column is born?

    I doubt that would be useful, I doubt "Nodes to consider" gets that much traffic , traffic for duplicates...

      I'm sure gods already thought of it when adding "prevent identical duplicates" feature and rejected it for some reason :)

      Doubt it.

      As I mentioned when LanX brought it up in chat yesterday, I'd also like the persisted nonce to be stored in the DB with the last-previewed text so a user could recover their unposted composition after a browser crash (if done quickly and not previewed anonymously).

      - tye        

        I thought this was sarcasm... :)

        Cheers Rolf

        ( addicted to the Perl Programming Language)

      > (identical duplicates should already be rejected)

      is it?

      Cheers Rolf

      ( addicted to the Perl Programming Language)

      > (identical duplicates should already be rejected)

      is it?

      Cheers Rolf

      ( addicted to the Perl Programming Language)

        have to test it again, both posts were not completely identical...

        Cheers Rolf

        ( addicted to the Perl Programming Language)

        update
        indeed, identical posts are suppressed: :)
        It looks like you've just tried to submit a node that has already been submitted. Luckily our staff in the control room was quick enough to press the Emergency Stop button before anyone got hurt.

        If you can't see your post, it probably hasn't been approved within its section by the moderators. Don't fret — go to Newest Nodes and chances are it'll be listed there. Others will see it as well, so sit back, relax, and enjoy PerlMonking.

        If you want to see unapproved nodes as well as approved ones, go to your User Settings and turn on "Show Unapproved Nodes".

        If you need to change something about your node, you can go to it and edit it, even after you have submitted it. Alternatively, you can reply to your own node. Whatever you do, don't re-submit the same content! Our system isn't so unstable that node submissions get dropped on the floor.

        have to test it again, both posts were not completely identical...

        Cheers Rolf

        ( addicted to the Perl Programming Language)

Re: Avoiding accidential reposts
by sundialsvc4 (Abbot) on Feb 26, 2014 at 16:01 UTC

    A still more practical solution would be to allow the owner of the post (necessarily excluding Anonymous Monk ...) to [soft-]delete his own posts.   Otherwise, the existing “consider” system probably works pretty well ... as does the system which says that, for a post to actually show-up, somebody other than the author probably had to give their nod to it.   I see little reason, little ROI, to come up with a technologically complicated system to deal with a circumstance that (a) only occasionally happens, and (b) when it does happen, can be “eyeballed.”   We do not want to make too much extra work for the programmers, nor for gods, who already do plenty-enough spam cleanup every day for the rest of us as it is.   (And we sincerely thank those of you who do that.)

    It’s not that I object – I don’t – but I find myself idly wondering, “okay, if we actually did that, and rolled it into production and so-on with all that such things entail, would it have been worth it? ... Would it turn out to be problematic, such that we had to back it out again?”   I am not automatically persuaded that these answers would be Yes and No.

      What is  [soft-]delete  supposed to mean?

      Many simple mortals like me are occupied with the consideration system not only gods and other group members.

      (even you could help, your rank is high enough)

      Saving us 1 min per day is worth the discussion since it allows us volunteers spending time in more useful things.

      Cheers Rolf

      ( addicted to the Perl Programming Language)

        Mea culpa, I am rather fond of HTML meta-characters.   Regardless of what you may have seen at the time you made this comment, now you should see left- and right-bracket characters.

        As for what you are saying here, Rolf, yeah ... you are preaching to the choir.   All of us are volunteers, and we all see the same Considerations.   Are pure-duplicate posts really now such an issue?   (He said, suddenly awkwardly ...) I don’t know ...