nus-se-bot
commented
3 years ago Team's Response
Thank you for the response! Our group has actually discussed this issue before and we decided that simply storing zoom links would suffice. From our experience this semester, in most cases, when we access a particular zoom link, we are automatically directed to the meeting without the need for a password. For cases where the meeting password changes every lesson, we believe that it is not viable and meaningful to save the zoom password in the application since we would have to edit the password every week/lesson. The user would already have to access luminus every lesson to retrieve the new password so it would not make sense for the user to use the application to edit the password. Editing the password means that the user has to, firstly, retrieve the new password from luminus, update the password on our application, and then retrieve the password prior to the lesson. He/she could have just accessed the password from luminus prior to the lesson and used the zoom link stored in our application to enter the zoom lesson. Adding a feature to store password seems irrelevant in this case and makes it more tedious for users as well. As such, we are rejecting this issue.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: Hi, thanks for responding to my bug report. I feel that this is indeed a feature flaw as your application is supposed to centralize key module details, contacts and information as stated in your UG. It would make sense (at least for me) to consolidate all information from luminus one shot into your application. This could be done perhaps at the start of the semester/once every few weeks when the future zoom links and passwords are made available to the students. Also, another point to consider would be that consultation sessions can have unique zoom links and require unique passwords too.
Having to access luminus everytime I wish to retrieve the password, as you have stated, for each unique zoom link contradicts the aim of your application of centralizing module details. I agree with you on the use case of editing password as I also do not see the value of doing so too. However, I was trying to say that being unable to have a consolidated list of zoom links and passwords saved in your application for me to copy paste into Zoom itself, made the functionality/feature of zoom link management less useful as a whole. To me, your proposed solution of accessing luminus to obtain the password and your application to retreive the zoom link, makes the zoom link management less useful too, since I could have just accessed both the password and zoom link from luminus entirely.
:question: Issue severity
Team chose [severity.Low]
Originally [severity.Medium]
- [x] I disagree
Reason for disagreement: I still feel that the severity should be medium, instead of low. The missing functionality of saving passwords, is likely to affect normal operation of the application. Since the user has to perform additional inconvenient steps of obtaining the password from luminus instead (I think the purpose of using your application is also to avoid the hassle of logging onto luminus). This can occur every week since tutorials/consultation sessions are weekly and hence it is not a rare occurence for this issue to be put under low.
Currently, the add zoom link function only supports adding a zoom link, but doesn't support adding the specified password for that particular zoom meeting. (As I have taken a few modules that require a new password for every meeting)
Perhaps, you could add a new optional field to include it in the zoom link management commands.