307457a255
Instead of going up the stacktrace to find the module names of waffle
flags and switches, we manually pass the module __name__ whenever the
flag is created. This is similar to `logging.getLogger(__name__)`
standard behaviour.
As the waffle classes are used outside of edx-platform, we make the new
module_name argument an optional keyword argument. This will change once
we pull waffle_utils outside of edx-platform.
Note that the module name is normally only required to view the list of
existing waffle flags and switches. The module name should not be
necessary to verify if a flag is enabled. Thus, maybe it would make
sense to create a `add` class methor similar to:
class WaffleFlag:
@classmethod
def add(cls, namespace, flag, module):
instance = cls(namespace, flag)
cls._class_instances.add((instance, module))
Status: Maintenance Responsibilities ================ The Student app supplements Django's default user information with student-specific information like User Profiles and Enrollments. This has made it a catch all place for a lot of functionality that we want to move into more dedicated places. For instance, while the CourseEnrollment models remain in this app for now, most Enrollment related functionality has already moved to the Enrollment app. If you are thinking of adding something here, strongly consider adding a new Django app instead. If you are extending something here, please consider extracting it into a separate app. Intended responsibility: Student dashboard functionality. Glossary ======== More Documentation ================== Plugins ------- Plugin Context view names (see ADR 0003-plugin-contexts.rst): * "course_dashboard" -> student.views.dashboard.student_dashboard