Note: Please read through all the instructions on this epic - we do not expect you to complete all of it at once, and you should definitely split it into separate issues and PRs. Feel free to tackle as much as you can, in order as specified below.
User Story
As an admin, I can turn chat on/off for a commons so that I have more control over game play.
Discussion
The idea is that the commons currently has a "showLeaderboard" field that can be true or false. We want a "showChat" field that works the same way. If the field is true, then users can interact with the chat. If it is false, only admins see the chat button (just like with the leaderboard). When it is true, backend endpoints related to chat work for all users (on that commons). When it is false, backend endpoints for the chat work only for admin users.
Suggested User Stories
I suggest this sequence; doing it in this order means that current functionality is never "broken" no matter where the dev leaves off. Each of these would be a separate issue / PR:
(1) A PR that adds the fields to the entity with a default value of true (this preserves existing functionality, since at first it's just an extra field in the table, hanging out with a default value of true, that isn't being looked at in the code anywhere else. Make sure that creating a new commons or editing an existing one still works.)
(2) A PR to make the backend endpoints respect the value of the field, meaning they will respond for regular users if/only if the showChat field is true, and return 403 if the field is false, but admins get responses no matter what the value of the field is. You won't be able to test interactively, but you can write unit tests that will manually set up a commons where showChat is false for purposes of the unit test. Again, at this point, no users facing functionality has changed, since there is no interactive way to set the chat field either through the backend or the frontend.
(3) Next, a PR adding the ability to set the field to true or false when doing the POST and PUT operations on the backend for commons. Now, as an admin, you can test interactively by using swagger to change the value (though you still can't do it via the normal user interface.)
(4) Finally, last step, a PR to add the checkbox to the CommonsForm so that you can change the value of showChat with a checkbox similar to that for showLeaderboard.
Bonus PR: Anytime after (1), though it makes more sense after (3) or after (4), you can add the showChat field to the CommonsTable that admins use to see all of the data for a commons. This is optional, because that table doesn't necessarily have to show everything; admins can click "Edit" if they want to see all of the fields for the commons.
Note: Please read through all the instructions on this epic - we do not expect you to complete all of it at once, and you should definitely split it into separate issues and PRs. Feel free to tackle as much as you can, in order as specified below.
User Story
As an admin, I can turn chat on/off for a commons so that I have more control over game play.
Discussion
The idea is that the commons currently has a "showLeaderboard" field that can be true or false. We want a "showChat" field that works the same way. If the field is true, then users can interact with the chat. If it is false, only admins see the chat button (just like with the leaderboard). When it is true, backend endpoints related to chat work for all users (on that commons). When it is false, backend endpoints for the chat work only for admin users.
Suggested User Stories
I suggest this sequence; doing it in this order means that current functionality is never "broken" no matter where the dev leaves off. Each of these would be a separate issue / PR:
(1) A PR that adds the fields to the entity with a default value of true (this preserves existing functionality, since at first it's just an extra field in the table, hanging out with a default value of true, that isn't being looked at in the code anywhere else. Make sure that creating a new commons or editing an existing one still works.)
(2) A PR to make the backend endpoints respect the value of the field, meaning they will respond for regular users if/only if the showChat field is true, and return 403 if the field is false, but admins get responses no matter what the value of the field is. You won't be able to test interactively, but you can write unit tests that will manually set up a commons where showChat is false for purposes of the unit test. Again, at this point, no users facing functionality has changed, since there is no interactive way to set the chat field either through the backend or the frontend.
(3) Next, a PR adding the ability to set the field to true or false when doing the POST and PUT operations on the backend for commons. Now, as an admin, you can test interactively by using swagger to change the value (though you still can't do it via the normal user interface.)
(4) Finally, last step, a PR to add the checkbox to the CommonsForm so that you can change the value of showChat with a checkbox similar to that for showLeaderboard.
Bonus PR: Anytime after (1), though it makes more sense after (3) or after (4), you can add the showChat field to the CommonsTable that admins use to see all of the data for a commons. This is optional, because that table doesn't necessarily have to show everything; admins can click "Edit" if they want to see all of the fields for the commons.