The metadata URL is invisible to the end user. The testday wiki page can easily get redirected to a different URL, e.g. when the event gets postponed (which happens all the time). The metadata URL can stay the same, no problem. Why do you want to change the metadata URL in this case?

The metadata URL is invisible to the end user. The testday wiki page can easily get redirected to a different URL, e.g. when the event gets postponed (which happens all the time). The metadata URL can stay the same, no problem. Why do you want to change the metadata URL in this case?

I believe this is for the deleting the event https://pagure.io/fedora-qa/issue/654

I have no experience of delaying events but just thought if event organizers used to change the wiki URL to reflect new date in URL then how does it work? or here we assume wiki testday page new URL is redirect from old page so it works that way?

The wiki redirect will take you to the new testday URL, yes. And you can also change the testday URL in the metadata, just always keep the metadata URL the same (never rename it).

It would be best to ask for testday app handling in a fedora-qa ticket next time and we'll set it all up, and also handle delays if needed.

@pnemade could you please elaborate on the reasons to allow changing the metadata URL? Apart of changing the URL itself (which is only used internally, and has no effect on the users) there is (IMO) nothing you'd gain from being able to do so.

I'm not saying it's impossible to implement, I just don't see any benefit in doing so. If you present some convincing usecases, I'd be happy to discuss the cost/benefit ration then.

@jskladan I mistakenly created pages with year in URL 2020 instead of 2021 and blindly created testday event. When I added redirects and tried same process again I got new event created https://testdays.fedoraproject.org/events/101 which become duplicate of https://testdays.fedoraproject.org/events/100

@kparal Ok. Thanks but i have been creating testday events since last few years this is first time I committed mistake in creating wiki pages and found no further help documented in https://fedoraproject.org/wiki/QA/SOP_Test_Day_management#Step_1

@pnemade so, IIUIC, the issue is "book keeping" to have the "correct looking" url of the metadata in order to easily find it/correlate it with the testday on wiki?

If so, I can appreciate the sentiment, I guess.

Looking at the code, this should be fairly easy to do, I guess, but before I go there, would you rather be able to delete a testday with no results, or change the metadata URL of an existing one?
Looking at the problem from the "defensive programming" side, I'd maybe rather enable the former, as it seems to be less prone to "random bot attack".

@jskladan Yes I agree with deleting the testday with no results in that case. Also, for security reasons, I am fine if deleting the event requires ticket to be reported to this project.

Regarding another option of hiding an incorrect test day entry:

I don't get what you mean. You'd add the "hidden tag" to the metadata page on the wiki, and then reloaded the testday in the admin interface, as if you made any other change. Testdays detects it's supposed to be not showing the testday, and it hides it. Done.

That works. But you have no way of displaying those "still in db but not showing on front page" events, so if you decide to unhide it for whatever reason later and you won't have the metadata url saved, you won't find it anywhere. I don't know how likely it is, just noting. This approach can also be used for malicious intent easier than deleting a testday with no results. (I'm not sure it's worth doing either, honestly. Shrug).

That works. But you have no way of displaying those "still in db but not showing on front page" events

I have no way of hiding/deleting the event either ;)

so if you decide to unhide it for whatever reason later and you won't have the metadata url saved, you won't find it anywhere.

If you "decide to unhide it" then by definition, you must have the url saved/the url must be known. Just saying...
And if you forgot it ever existed, then you'd just create a new one, as if it never did. I don't really see the issue here.

I don't know how likely it is, just noting.

IMO not likely.

This approach can also be used for malicious intent easier than deleting a testday with no results

I believe it's either absolutely the same, or harder for a "random automated bot" to change tons of wiki pages in a specific way, than randomly bomb a "delete" button on a page. But since we had literally no malicious behavior in the years of running the testday, it probably is a moot point anyway.

I have some spare cycles, so I'll most probably end up implementing either one of these methods, and I'll close the ticket once it's done.