[pkvach]

Checklist

• All new and existing tests are passing
• (If adding features:) I have added tests to cover my changes
• (If docs changes needed:) I have updated the documentation accordingly.
• I have added an entry to CHANGES.rst because this is a user-facing change or an important bugfix
• I have written proper commit message(s)
  

What changes does this Pull Request introduce?

A thread can be marked read-only from the new Threads page of the admin interface (/admin/threads/). The state is stored per-thread in the database and enforced on the server: the comment-fetch response reports it, and new comments, edits and deletions are rejected for a read-only thread. Existing comments and votes are unaffected.

The embed client reads the flag from the fetch response and hides the postbox and the reply/edit/delete controls to match.

Example

• Normal mode:

• Read-only mode:

This feature is useful for archived content, closed discussions, or when comments should be visible but not interactive.

Why is this necessary?

Related to: #1039

[jelmer]

Any reason this is client side only? If we stored this on the server than we could: actually enforce this, allow controlling it from e.g. the admin panel, wouldn't need JavaScript hackery to enable.

[pkvach]

Any reason this is client side only? If we stored this on the server than we could: actually enforce this, allow controlling it from e.g. the admin panel, wouldn't need JavaScript hackery to enable.

Thanks for the feedback.
You are right. Server-side enforcement gives stronger control and real locking.

I chose a small and safe change first. A client-side flag is quick to add and handles simple cases like soft close or login requirement. No backend or database changes.

A server approach needs more work, thing like:

• Add thread read and update APIs.
• Update database schema.
• Build admin UI to manage thread state.
• Make the client check thread status on each load.

I avoided this scope for now, though I agree it makes sense for a future update.

If there's interest in a server-side solution, I'd be happy to help plan or contribute to that as a follow-up.

[BBaoVanC]

I think this only makes sense to merge if it were server side. Otherwise someone could trivially edit or bypass the client-side UI and post to a thread you intended to be read only. Instead of configuring read only status client-side on the page, the client could request the read only status of the thread from the server while it loads, then hide the postbox based on what the server says.

[pkvach]

Yes, I understand that a server-side solution is the better approach here.
I'll convert this PR to draft and try to rework it. Thanks for your feedback.

[fluffy-critter]

I think that this client-side-only approach would handle my particular use case pretty well and I'd still like to see it show up. The purpose of the original feature request was to make posting ability conditional based on aspects of the client and it's not like Isso conversations are a high-security thing; having something that's a basic barrier to entry for AI agents and drive-by trolls is all I particularly care about.

Also, a situation where the only way to close comments on a thread is for an admin to shut it off entirely within the database is completely useless for my needs.

An approach where the server presents some sort of signed token to the client (using a basic HMAC-type approach), which needs to be present for the post to work, would be nice. For example, having data-comment-token="[some random string]|[md5sum of the same random string concatenated with a secret security key]", and server-side configuration where if the security key is present and data-comment-token isn't, the reply field doesn't appear. That also wouldn't require any database changes on isso, and would satisfy all of the use cases I can think of.

[jelmer]

I think that this client-side-only approach would handle my particular use case pretty well and I'd still like to see it show up. The purpose of the original feature request was to make posting ability conditional based on aspects of the client and it's not like Isso conversations are a high-security thing; having something that's a basic barrier to entry for AI agents and drive-by trolls is all I particularly care about.

Also, a situation where the only way to close comments on a thread is for an admin to shut it off entirely within the database is completely useless for my needs.

An approach where the server presents some sort of signed token to the client (using a basic HMAC-type approach), which needs to be present for the post to work, would be nice. For example, having data-comment-token="[some random string]|[md5sum of the same random string concatenated with a secret security key]", and server-side configuration where if the security key is present and data-comment-token isn't, the reply field doesn't appear. That also wouldn't require any database changes on isso, and would satisfy all of the use cases I can think of.

Why wouldn't isso comments be a high security thing? I don't see why they couldn't be - and at the very least we shouldn't do things to make it's security profile worse.

Also, wouldn't users still be able to edit their comments with this PR despite a thread being read only? And users can still delete their comments? And pretty sure AIs will easily work out how to just send the magic POST request necessary.

I think if this was called something like "hide comment create form" I could be onboard with it. As implemented, I think it is misleading users into thinking it is more than it is.

[fluffy-critter]

Fair points! I think the main thing I was getting at is that the proposed alternative of doing purely server-side thread-level locking isn't suitable for the original request.

Calling this PR "hide comment create form" would be fine. I'll update the original issue with my implementation thoughts, in any case.

[fluffy-critter]

@pkvach Being able to lock a thread from the admin panel is useful but it's not what I was looking for with this; for example, I was hoping to make it so that I can require someone to log in to my website to be able to post a comment, while still being able to display the thread to people who aren't logged in. As such, this PR wouldn't actually close the referenced issue.

[pkvach]

@pkvach Being able to lock a thread from the admin panel is useful but it's not what I was looking for with this; for example, I was hoping to make it so that I can require someone to log in to my website to be able to post a comment, while still being able to display the thread to people who aren't logged in. As such, this PR wouldn't actually close the referenced issue.

Thanks for the feedback! I agree that the current changes don't meet your needs, so I'll change the reference to the issue. I may consider working on that implementation once this PR is resolved.

[fluffy-critter]

Excellent, thanks for understanding. :)