Replace an old FIXME comment with an explanation why a fix is not nee…

[sayravai]

…ded. Fix another FIXME in the same file by using Django time formatting.

Description

This PR only replaces an old FIXME comment by an explanation. It also fixes another FIXME in the same file by using Django datetime formatting to match user settings instead of a default datetime string.

What the old FIXME is about

CourseVisiblePermissionBase.is_object_visible() (course/permissions.py) decides whether a CourseInstance is visible by looking at the view_content_to field of the course instance (PUBLIC / ENROLLMENT_AUDIENCE / ENROLLED). The FIXME says the check should probably also consider the view's get_access_mode(): if the view declares itself ACCESS.ANONYMOUS (i.e., "anyone may access this view"), the course should arguably be treated as visible even if view_content_to != PUBLIC.

Why it was never done — the reason is still accurate today:

For normal UI views it's redundant. AccessModePermission runs before this permission (lib/viewbase.py adds it first), and CourseInstanceBaseMixin.get_access_mode() (course/viewbase.py:152) already loosens STUDENT/ENROLL views to ANONYMOUS exactly when the instance is public — using the same view_content_to field this permission checks. So an "ANONYMOUS access mode" would imply PUBLIC anyway, and the check adds nothing.

For API views it would break things, like the original FIXME's warns. API resources never really use access modes: course/api/mixins.py:17 and exercise/api/mixins.py:40,66 hard-code access_mode = ACCESS.ANONYMOUS with the comment "not really used" (it exists only so super().get_access_mode() doesn't crash). exercise/api/views.py:449 even does the opposite hack — returning ACCESS.STUDENT/ENROLL regardless of the course's visibility, "so that enrollment exercises work in the CourseVisiblePermission". If is_object_visible() consulted view.get_access_mode(), every API course — public or not — would look "anonymous/public" to non-enrolled users, bypassing the view_content_to and enrollment-audience checks.

So the "hole" is theoretical: no UI view today declares ANONYMOUS while the instance is non-public (everything public gets it via the loosening logic, e.g. course/views.py:42,102,124,145 plus the rule in viewbase.py), and the API deliberately hard-codes it to ANONYMOUS, which is exactly the case we must not trust.

Why?

[ANSWER HERE]

How?

[ANSWER HERE]

Fixes #

Testing

Remember to add or update unit tests for new features and changes.

• How to test your changes in A-plus
• How to test accessibility

What type of test did you run?

• Accessibility test using the WAVE extension.
• Django unit tests.
• Playwright tests.
• Other test. (Add a description below)
• Manual testing.

[ADD A DESCRIPTION ABOUT WHAT YOU TESTED MANUALLY]

Did you test the changes in

• Chrome
• Firefox
• This pull request cannot be tested in the browser.

Think of what is affected by these changes and could become broken

Translation

• Did you modify or add new strings in the user interface? (Read about how to create translation)

Programming style

• Did you follow our style guides?
• Did you use Python type hinting in all functions that you added or edited? (type hints for function parameters and return values)

Have you updated the README or other relevant documentation?

• documents inside the doc directory.
• README.md.
• Aplus Manual.
• Other documentation (mention below which documentation).

Is it Done?

• Reviewer has finished the code review
• After the review, the developer has made changes accordingly
• Customer/Teacher has accepted the implementation of the feature

Clean up your git commit history before submitting the pull request!

[ihalaij1]

Nice!