Streamline thread exporting

[Tyrrrz]

Exporting threads is still not very well-supported by DCE.

Currently, the following is already possible:

• Export a thread by ID (CLI, using export)
• Show a list of all threads in a guild (CLI, using channels)

We need to also support the following:

• [x] Extend exportall to include threads as well, when --include-threads is passed (CLI)
• [x] Extend exportguild to include threads as well, when --include-threads is passed (CLI)
• [x] Show a nested list of active threads underneath each channel, when the corresponding setting is enabled (GUI)
• [x] Show a nested list of archived threads underneath each channel, when the corresponding setting is enabled (GUI)

We also need to rework how the data is pulled in GUI. Currently, we pull all guilds and their channels ahead of time. If we include threads there, this process may start taking hours to complete. So instead the GUI should pull only channels (and threads) that belong to the currently selected guild. This will also help with #1005.

With the above points implemented, thread exporting functionality will be considered feature-complete within the current scope of the project.

[CanePlayz]

Currently other open issues with threads:

• [ ] HTML exports are missing the content of the first message
• [ ] Path variables need to be rethought
• [x] Trying to export threads with a bot token for some reason yields a bad request issue on some voice channels

(Potentially an option to not put them inside a folder but on the same level as their parent channel with default naming like Parent channel name - Thread name. Don't know if others would be interested in this as well, just a personal preference, so I'm, interested in what others think.)

[Tyrrrz]

• Threads currently get exported in a folder that is on the same level as server categories, but it should be inside the directory of the category of the parent channel

Can you please provide more details on this?

[CanePlayz]

• Threads currently get exported in a folder that is on the same level as server categories, but it should be inside the directory of the category of the parent channel

Can you please provide more details on this?

Currently, my export path looks like this:

Server\\%G\\%P – %T\\%p – %C.html

When I export a server with threads, I get the following folders in the %G subdirectory:

• Categories (as intended)
• Folders named like a channel with their threads inside

Trying out the default behavior when there are no other specifications than %G in the path seems to lead to all channels in one folder. I hadn't tried this out before so I assumed the folder-thing was the default behavior. I suggest we either add a naming convention like Parent channel name - Thread name for threads or put them inside a folder that is located on the same level as the parent channel file.

[Tyrrrz]

Hmm, threads to channels have the same relationship as channels do to categories. Wouldn't it make sense that the threads would be grouped by channels?

[CanePlayz]

Hmm, threads to channels have the same relationship as channels do to categories. Wouldn't it make sense that the threads would be grouped by channels?

Yeah sure, absolutely. But channels to threads are one level below categories to channels.

Categories -> channels -> threads. So grouping them into folders by default would be a good solution.

However, with the current parameters I'm using, it looks at a thread and doesn't take into account that its parent channel is still in a server-level category. It uses %P – %T as the thread's category (which is the parent channel), instead of the parent channel's category.

[Tyrrrz]

Can you please provide an example of a file structure that you'd expect and the current one, with sample file names. It's hard to understand in abstract terms 😅

[CanePlayz]

Can you please provide an example of a file structure that you'd expect and the current one, with sample file names. It's hard to understand in abstract terms 😅

Yeah sure. It's pretty hard put into words.

I think two different topics have emerged out of this:

Default exporting structure for threads

Currently, threads get just into the same folder as their parent channel. I've talked about the option to export them into one folder, but after more thought, this could be solver in a different way. More on that further down.

Path parameters

These need to be rethought with threads because DCE uses the same given path for both channels and threads. That messes with threads. Let's look at the following example:

\\%G\\%P – %T\\%p – %C.html

It essentially means:

Server\\Category\\Channel.html

This should result in the following structure:

Server name
|
|-- Category name 1
|     |
|     |-- Channel name 1 
|     |-- Channel name 2
|     |-- Thread of channel 1

If I export a channel, the term gets evaluated properly.

However, if I export a thread, the term doesn't get evaluated properly. Here's why:

%P – %T will evaluate to the parent channel, because that is "the thread's category", instead of using the server-level category.

Ultimately, this means that you will end up with something like this:

Server name
|
|-- Category name 1
|     |
|     |-- Channel name 1 
|     |
|     |-- Channel name 2
|
|-- Channel name 1
      |
      |-- Thread of channel 1

Possible solutions would be:

• Let the user pass separate paths for threads and channels
• Just evaluate the given path for channels. For threads, evaluate the same term for the parent channel and put the threads inside whatever folder their parent channel is in.

The first option would be more flexible, clearer to the user, and also remove the need for the aforementioned option of putting all threads of one parent channel into one folder, as you could just give a path that will handle that. However, we'd need two more parameters: one for the name of a parent channel and one for a thread's name.

[Tyrrrz]

@CanePlayz I see, thank you for the detailed explanation. It seems that fixing that would require a bit more work, so I'm not going to include it in this issue. Please create a new issue for now (you can copy-paste your comment above).

[Tyrrrz]

I will close this now since all originally mentioned tasks have been completed, albeit with subpar UX.

[CanePlayz]

@CanePlayz I see, thank you for the detailed explanation. It seems that fixing that would require a bit more work, so I'm not going to include it in this issue. Please create a new issue for now (you can copy-paste your comment above).

👍