TL4s posting in archived topics

support
1

Is this a bug, or an intended feature? If it’s intended behavior, how can I restrict it, if at all?

I’ve closed a number of threads as no longer timely. I’ve been making regular updates about our transition from the old software to Discourse. The problem is, our TL4s (local representatives) keep posting in them anyway. Yes, I can delete and redirect (which is what I have been doing). So I figured, okay, archives are supposed to be unchangeable, so let’s go there.

So I archived the post.

They’re STILL able to post there. My understanding of archives is that it’s supposed to disallow posting, likes, etc. However, for TL4s, it doesn’t. It makes sense for staff to be able to update archived topics, but TL4s aren’t staff.

So how the heck do I actually lock these posts down so people will stop updating? Removing TL4 isn’t really an option (the group in question needs it for a number of reasons.) A lot of this is education, yes, but we all know how well people read and pay attention to instructions. The point of an archive is to lock it down, to freeze it in carbonite. If the community can still interact with it, it’s not archived. I’m not worried about them being able to un-archive; that’s fine. It makes sense. They need to at least have to have that step between being able to post and not.

2

OKay, yeah, I finally found it with some research. Yes, this is intended behavior.

However, I’m going to say that this makes the archive function kinda weird. It seems to me like archives should be just that… archived. If you need to make a change, you should have to unarchive them to do so. Otherwise, there’s no functional difference between closing and archiving beyond the ability to like a post or not.

3

There is some confusion in the several discussions of archived topics.

Maybe the following points might clarify the conceptual space and how Discourse archiving appears to fit within it:

1. The ability to edit archives in Discourse is by-design for TL4 and up. It is not a mistake or omission.

Contrast this with the frozen in carbonite statement from 2015 which clearly does not match the reality of the Discourse archive feature.

It is unfortunate that that post persists in quote after quote. It sounds and looks good but it sets an unrealistic expectation that nothing will ever change in an archive. That has never been the case in the real world where information can always be added or amended for archived items.

2. In general, there are two key characteristic of archives: stored and unpublished

  • they are preserved for posterity because they have some desired value.
  • they are transferred to and stored in an “unpublished” state.

Conceptually, there is a clear distinction between using libraries to access published items and using archives to access unpublished items.

This distinction is breaking down in real usage due to archives increasing their use of electronic catalogs and digital imaging of items. This means that archive items or their reproductions are increasingly accessible through library systems.

That is much the same situation in Discourse where archived topics remain listed but don’t appear in all lists. Unlisting a topic makes it more like a traditional archive item requiring additional effort to find it in a segregated silo.

3. We interact with archive topics in Discourse function much like we handle archive items in real life.

We can access the archive zone (room, locker, shelf, folder, file, …) and we can access any item to add to it, annotate or tag it, loan it, and remove it e.g. to destroy it.

So it is not normal in the real world to unarchive an item to make such changes except when destroying it or otherwise permanently removing it from the collection.

Here’s the reason why. In the real world changing status involves physical effort so we would not do it unless the status change is permanent, e.g. move box out of storage to different building, delete catalog entry and update indexes, stamp box as removed from archive so it doesn’t accidentally get returned.

In the digital world it is effortless to change the status of an archive item. It is feasible to implement that logic but it diminishes the usefulness of the term archive.

1 Like
4

The problem is, this quote is from the developers, and is regularly referred to in the how-to documentation here. If this is not the reality of the implementation, one of two things needs to happen:

  1. The documentation needs to change so that it clearly reflects the reality of the active feature.

  2. The active feature needs to be updated to reflect the original design and intent.

This is the understanding I have of an archive; in order to change it, you must remove it, physically, from the archive. It would make sense for similar behavior in digital form.

The problem I’m having is the functional difference between closed and archived is so minimal as to be nearly pointless. Closed or archived; closed means closed to further comments, to me. Archived means “can no longer be changed” when compared specifically to closed.

Unlisting is an entirely different function unrelated to archiving, and isn’t relevant here. That’s why it’s a different function separate from archiving.

In my situation, I don’t want to unlist the damn things, I just want people to stop replying to them! They have useful historical information, they’re just no longer relevant to current complaints/functionality. If I only want them accessible by link, then I’d unlist them.

That’s the whole point of closing, and later archiving.

As for real-world comparisons… archives on the web, particularly of forums, are always read-only. They’re provided for historical purposes, not “let’s update this when we need to.” You look, but you don’t update. That’s why you have them. This feature is not, currently, functioning like an actual archive. You’re not intended to add to a digital archive. You may add new items to the archive, but you don’t open up existing ones and make changes. If you need to do that, they shouldn’t be in the archive because they’re active and relevant.

If you want something that is no longer relevant but is still updatable, you close it. Closing being a status that is irrelevant to TL4 and above makes sense.

5

This isn’t a technology problem, if your TL4 users don’t respect a request not to respond to closed or archived topics then they probably shouldn’t be TL4.

OTOH if you haven’t asked them not to interact with such topics that’s a totally different matter.

1 Like
6

A plugin might resolve your technology problem though: don’t allow post add/modify in archived topics. It could prove the popularity of your preferences. If it become popular then maybe the changes you want could be incorprated into Discourse.

The visual is an incomplete representation. I prefer to look at the actual functionality rather than metaphors.

I said changing status from archived to unarchived which is a larger task than changing the archived item itself.

Not true. Discourse archiving substantially removes the topic from the user interface. The main path to find some topics is then explicit links. Archiving is like a partial unlisting to reduce casual interactions:

Unlisting completes the delisting process which is why it is relevant.

Technically, most archives on the Web are “snapshots” of the presentation layer. That is also why they are usually read-only because they do not incorporate the entire entity they represent. They are more like photographs, as snapshot suggests. They usually lack the program code and database structure that are necessary to allow further interaction with the original entity.

Looking more specifically at forum archives (and blogs, email, and other media types), there are varying levels of interaction available. All archives are not read-only and many can be unarchived simply by clicking restore/publish. The further the archive is from the core forum code and data structure then the more read-only it usually becomes. I know that some forums have problems unarchiving where the original categories no longer exist. Discourse archiving avoids that problem.

1 Like
7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.