Sometimes, people create a wrong event by accident. It's quite easy to do, just paste a wrong URL (see e.g. #32). Technically, there's no problem in having a wrong event in the database, we don't care. But users might get confused when they see it on the main overview page and start filling out something that wasn't meant to be filled out.
A good-enough solution could be to allow hide (and unhide) events from the main page, using the admin interface.
If we were to implement this, we would also have to add some auth method in my opinion (the admin interface doesn't use any authentication at all).
Sometimes, people create a wrong event by accident. It's quite easy to do, just paste a wrong URL (see e.g. #32). Technically, there's no problem in having a wrong event in the database, we don't care. But users might get confused when they see it on the main overview page and start filling out something that wasn't meant to be filled out. A good-enough solution could be to allow hide (and unhide) events from the main page, using the admin interface.
I am happy if this is possible to implement.
I am -1 to this. The admin interface is kept open so that maintainers can add their own test cases, edit the meta and update the event. Keeping an auth there would mean people will need a new account (for rhel or redhat folks ; opening another FAS just to add a test case is PITA) or need the password to share in case this is not OAuth/OIDC.
As we move forward people might actually wanna go ahead and run their own test day. Adding more authentication adds to the problem doesnt make it easier.
I am -1 to this.
If we were to implement event hiding, there just simply HAS to be some authentication. That is not up for discussion, we can't leave plain /admin with nice "Disable event" buttons wide open for anyone who tries to open /admin to play with.
The admin interface is kept open so that maintainers can add their own test cases, edit the meta and update the event. Keeping an auth there would mean people will need a new account (for rhel or redhat folks ; opening another FAS just to add a test case is PITA) or need the password to share in case this is not OAuth/OIDC.
Why would anyone need another FAS account? Having one works just fine.
Let me be clear here, if someone wants to prepare a test day, clicking on login button will take about 2 seconds of their time. That's what, 1/1800th of the time to prepare a test day at bare minimum?
I am -1 to this. If we were to implement event hiding, there just simply HAS to be some authentication. That is not up for discussion, we can't leave plain /admin with nice "Disable event" buttons wide open for anyone who tries to open /admin to play with. The admin interface is kept open so that maintainers can add their own test cases, edit the meta and update the event. Keeping an auth there would mean people will need a new account (for rhel or redhat folks ; opening another FAS just to add a test case is PITA) or need the password to share in case this is not OAuth/OIDC. Why would anyone need another FAS account? Having one works just fine. As we move forward people might actually wanna go ahead and run their own test day. Adding more authentication adds to the problem doesnt make it easier. Let me be clear here, if someone wants to prepare a test day, clicking on login button will take about 2 seconds of their time. That's what, 1/1800th of the time to prepare a test day at bare minimum?
I agree with the premise. I object to the "oh now I need another account" if I don't have FAS that is. Many of the folks in RHEL don't have a FAS account and nor would they want to have one; unless it's non-optional convention. Lets do the auth, but then update all the SOP with this feature in our test day docs.
I am -1 to this. If we were to implement event hiding, there just simply HAS to be some authentication. That is not up for discussion, we can't leave plain /admin with nice "Disable event" buttons wide open for anyone who tries to open /admin to play with. The admin interface is kept open so that maintainers can add their own test cases, edit the meta and update the event. Keeping an auth there would mean people will need a new account (for rhel or redhat folks ; opening another FAS just to add a test case is PITA) or need the password to share in case this is not OAuth/OIDC. Why would anyone need another FAS account? Having one works just fine. As we move forward people might actually wanna go ahead and run their own test day. Adding more authentication adds to the problem doesnt make it easier. Let me be clear here, if someone wants to prepare a test day, clicking on login button will take about 2 seconds of their time. That's what, 1/1800th of the time to prepare a test day at bare minimum? I agree with the premise. I object to the "oh now I need another account" if I don't have FAS that is. Many of the folks in RHEL don't have a FAS account and nor would they want to have one; unless it's non-optional convention. Lets do the auth, but then update all the SOP with this feature in our test day docs.
If only @redhat is the issue, can we not have an auto auth for people with valid @redhat.com account? I do agree that any administrative action must be authorized.
I intentionally left it vague when filing this ticket, so that we can discuss implementation options when we're ready to work on it. But my assumption was that we probably won't require authentication for hiding events, at least in the short term. The reason is that implementing auth is hard, we already fight with it in blockerbugs and packager dashboard and basically everywhere. If we required auth for this, this ticket will be blocked and will likely take a long time before it's done. If we don't require auth, it's likely that this can be implemented quite quickly.
While hiding an event from the main page by anyone who knows the admin interface address is bad, is it worse then completely wiping the testcases from the event, possibly even during the test day? Because that's exactly what anyone can also do, right now. I feel that hiding an event (I intentionally didn't suggest removing) is a small nuisance compared to that. So yes, we do need some auth in the future, but I don't think it needs to block this ticket.
I've filed #35, please feel free to discuss authentication implementation there, if you want :-)
Let's keep this ticket for discussing how to best implement event hiding (a button in admin interface, a special keyword in the wiki, etc). A note on this subject - if we're going to have hidden events, we should also have an easy way to display them. There can be a toggle on the overview page, accessible to all. Or the hidden events can be listed just in the admin interface. Or possibly something else.
Log in to comment on this ticket.