Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove private TextAnswers #2363

Open
janno42 opened this issue Jan 6, 2025 · 1 comment
Open

Remove private TextAnswers #2363

janno42 opened this issue Jan 6, 2025 · 1 comment
Labels
[C] Backend Focuses on backend implementation [C] Frontend Focuses on frontend implementation [P] Medium Medium priority [T] Refactoring Existing parts should become faster, more readable, or in any other way better.

Comments

@janno42
Copy link
Member

janno42 commented Jan 6, 2025

Private TextAnswers were added (in #530) for this purpose: A tutor/PhD student receives valuable feedback that we want to give them but don't want the responsible professor to see (e.g., because it directly or indirectly criticizes the professor). Back then, responsibles could see all TextAnswers.

Since #1279, responsibles can no longer see all TextAnswers, only those about themselves and those for general questions. The only case in which users can see other users' TextAnswers (besides reviewers/managers) is if they are delegates of those users. Usually, PhD students can be delegates of professors, but hardly the other way around. So the original use case no longer exists.
Private TextAnswers have rarely been used in recent semesters (and those instances aren't critical), so we can

  • remove private TextAnswers completely from the codebase.
  • All TextAnwers currently marked as "private" should be changed to "public".
  • The ReviewDecisions should be renamed to "publish"/"delete"/"undecided".
@janno42 janno42 added [C] Backend Focuses on backend implementation [C] Frontend Focuses on frontend implementation [P] Medium Medium priority [T] Refactoring Existing parts should become faster, more readable, or in any other way better. labels Jan 6, 2025
@niklasmohrin
Copy link
Member

Just a thought while we are at it, how do we feel about something like "keep" instead of "publish"? Or maybe "approve"? There isn't really a reason to change, but we might as well pick the one we like best while we rename it

(The discussion from the previous rename is #1776)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[C] Backend Focuses on backend implementation [C] Frontend Focuses on frontend implementation [P] Medium Medium priority [T] Refactoring Existing parts should become faster, more readable, or in any other way better.
Development

No branches or pull requests

2 participants