Re^6: A reply falls below the community's threshold of quality. You may see it by logging in. (Acolyte Level=3 needed)

IIRC two places need to be patched - shownote and std_node_display

No; std_node_display already had the distinction. In fact, that's where I got the text for the patch for shownote.

sometimes a hardcoded level -9 is used otherwise a system wide HTMLVARS² crap_threshold = -4

Right. The idea is:

If it's merely bad (<-4), don't show it to not-logged-in users, but logged-in users can see it.
But if it's very bad (<-9), don't show it to logged-in users below a certain level (<=3).

Unfortunately some of these values are hard-coded.

We could add a system variable like $HTMLVARS{supercrap_threshold} if you want. I hesitate to add any htmlcode for this.

does Annomonk have two system wide identifiers like guest- and default-user

Yes. They are interchangeable and both refer to AnonymousMonk.

Comment on Re^6: A reply falls below the community's threshold of quality. You may see it by logging in. (Acolyte Level=3 needed) Download Code

Replies are listed 'Best First'.
Re^7: A reply falls below the community's threshold of quality. You may see it by logging in. (Acolyte Level=3 needed) by LanX (Saint) on Apr 23, 2026 at 15:48 UTC
Up to you. 🤷🏻‍♂️ Personally I'd simplify the system. Less code easier rules, central config. One unified `crap_threshold` , one `crap_min_user_level` and the same clause everywhere and the same message °. Minimal boilerplate, hence no htmlcode needed. The idea is once users are passed `crap_min_user_level` they are mature enough to handle "crappy" nodes. I suppose handle_threaded_nodes has to be patched too, to ensure that logged in users only see RAT entries of nodes they can access. Edit °) You might link the message to a doclet with an explanation mirroring the current settings. But that's an extra, and I'm not sure it's worth it. Cheers Rolf _{(addicted to the Perl Programming Language :) see Wikisyntax for the Monastery}	[reply] [d/l] [select]

Replies are listed 'Best First'.

Personally I'd simplify the system. Less code easier rules, central config.

One unified crap_threshold , one crap_min_user_level and the same clause everywhere and the same message °.

Minimal boilerplate, hence no htmlcode needed.

The idea is once users are passed crap_min_user_level they are mature enough to handle "crappy" nodes.

I suppose handle_threaded_nodes has to be patched too, to ensure that logged in users only see RAT entries of nodes they can access.

°) You might link the message to a doclet with an explanation mirroring the current settings.

But that's an extra, and I'm not sure it's worth it.

Cheers Rolf
_{(addicted to the Perl Programming Language :)

see Wikisyntax for the Monastery}