Is your feature request related to a problem? Please describe.
Currently, all paths to the task public files put in any of the task statements, even in relative paths, have to contain the taskid because there is no trailing / in the tasks URLs. That does not ease task redistribution, and no mechanism can warn the user if they forget to update the rst fields.
Describe the solution you'd like
Whatever that would allow not to repeat the taskid, that would not introduce regressions, with a clean implementation.
Possibilities:
Templating layer with a specific variable generating the path: impacts performance but would allow more possibilities in the future, such as putting directly the random generated values or other task-related values (currently injected in JS) directly into the HTML code.
Hooking the reStruturedText directives: that could be subject to many errors and non-exhaustivity, because that does not concern the image directive only.
Playing with the routes: this is probably the lightest implementation possible. Actually, replacing the /<courseid>/<taskid> route by /<courseid>/<taskid>/whatever and /<courseid>/<taskid>/<path> by /<courseid>/<taskid>/public/<path> would allow simply putting links such as public/<path> in the rst descriptions. However, the same problem happens if we want to ensure retrocompatibility. In this case, I would suggest design a task updater instead of ensuring retrocompatibilty.
Is your feature request related to a problem? Please describe.
Currently, all paths to the task public files put in any of the task statements, even in relative paths, have to contain the taskid because there is no trailing
/in the tasks URLs. That does not ease task redistribution, and no mechanism can warn the user if they forget to update the rst fields.Describe the solution you'd like Whatever that would allow not to repeat the taskid, that would not introduce regressions, with a clean implementation.
Possibilities:
imagedirective only./<courseid>/<taskid>route by/<courseid>/<taskid>/whateverand/<courseid>/<taskid>/<path>by/<courseid>/<taskid>/public/<path>would allow simply putting links such aspublic/<path>in the rst descriptions. However, the same problem happens if we want to ensure retrocompatibility. In this case, I would suggest design a task updater instead of ensuring retrocompatibilty.