-
-
Notifications
You must be signed in to change notification settings - Fork 702
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make template tokens work properly for export paths of threads #1123
Comments
The issue is that, within the current framework, we only know about the given channel's parent. So for a channel – it's the category, and for a thread – it's the parent channel. We could try to add a new token that evaluates to the full path (what to name it?), but we would have to pull that information early and embed it within the |
Nevermind, we should be able to evaluate the full path as is. I still think we need a new token for this, but I'm not sure. Thoughts? |
I can propose the following solution: |
Isn't that what – according to my example above – What we'd essentially really want there is to be able to access the category when exporting a thread instead of only accessing its parent channel, so that a structure like this could be achieved:
|
Sorry, you're right. I mistyped. In case of a thread it would also be the category. |
I'm a bit wary about making assumptions anymore, after Discord added threads. In this case, it's better to expect that channels might eventually have deeper hierarchy than 1 or 2 levels, or that there might be channels that are completely outside of categories. One thing we can expose is the hierarchical name of the channel/thread as one token -- i.e. The issue with the root parent token proposal is that for channels both |
Interesting. I like the general idea of that as it would behave differently for channels and threads and therefore only require one path argument. However, it would limit the folder and file names to just being the plain category/channel name without extra modifications.
Yeah, same concern as the one above.
Yeah, the solution with two added tokens would require separate arguments for channel and thread paths, so while it might look elegant at first, it might not be that easy to implement. |
There is an another option - let user export only threads without channel. Then the user can run two commands - first one to export channels, second one to export threads - for each command the user can pass different path (achieving option 1) |
This is already the case. I'm assuming @CanePlayz's issue is when you export multiple types of channels at once. |
This could work, but it might be confusing that the supplied path is actually for the parent channel (which may or may not be exported at the same time), and that the actual path will be somewhat different. |
Yup, that would be confusing and also limit the possible paths quite hard. |
…be set recursively. Tyrrrz#1123. e.g.: "\%G\%r%P – %T%r\%p – %C.html"
Version
v2.40.4
Flavor
GUI (Graphical User Interface), CLI (Command-Line Interface)
Platform
Any
Export format
No response
Steps to reproduce
Export threads and use template tokens in the path
Details
Path parameters 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:
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:
Possible solutions would be:
The first option would be more flexible, and clearer to the user. However, we'd need two more parameters: one for the name of a parent channel and one for a thread's name.
Checklist
The text was updated successfully, but these errors were encountered: