delete courses, events, users...

[1u]

mark them as deleted (by: user_id, on date, reason string)

(or move them into own collection)

• admin view to manage them

[sbalmer]

Why would we even want to delete a course?

1. When it's old and incomplete, maybe.
2. It's spam
3. It's a troll entry
4. Other violations of guidelines

Established courses should be hard to delete because it would erase a lot of history. So it is only insignificant courses that get deleted. Archiving is desired, so that the decision to delete can be reversed. Browsing the deleted courses would be a strictly administrative subject, visitors need no access. How could we implement deletion?

1. Add a flag to the course that marks it as deleted
2. Move the course to a special collection for archived courses
3. Log the removal including the entire course object to a log-collection

Method one would be the simplest initially. There is a long tail of queries that need adjustement so they don't publish archived entries however. It's not good practice to keep archived (well, deleted) data among live data because you'll eventually confuse the documents. The needs are different too. Where active courses are a living thing where modifications are expected and frequent, deleted courses are not expected to change at all.

Methods two and three are similar technically. The difference is in whether the archive is specific to the course type or whether other documents may be logged too. The prospect of having a 'shadow' collection for every collection just to hold deleted documents is not a agreeable idea. Initially, we might get by just having one for courses and events each. But even those would have massive overlap regarding the metadata that'd be stored with each deletion event. It could even mean that we have to duplicate metadata because we're deleting a course with an attached event.

[1u]

Emre says: I think solution 2 is the better way to go. keeping live and archived courses and events separately will be useful since the "live" and "archived" collections will have different read/write frequencies, and in the future when we need to optimize on this level and create mongodb shards, we can focus more on the "live" collection, this would keep things more manageable.

[1u]

An other problem is that Courses and Events might get deleted unintentionally...

As we as well have to care about updating (db-structure for example) and we can make publication-rules I personally still tend to solution 1. we can still put it into own collections later if it would help solving any performance-issues.

[1u]

Maybe archiving is enough: #595

Some examples of courses that might be deleted or archived:
Massage
alles ums netz

[schlauberg]

I hope I'm in the right thread, if not please let me know and I'll open a new issue.
At the moment deleted users in Diskussions and in courses are represented by "?!"
[deleted user] might be more helpful in comments and otherwise. I guess removing deleted users from courses (and other possible places) would be great, but that might be already done by cronjob.(?)