will-r-wang / cmslearn-course-management-system Goto Github PK

Once the basic functionality of the CMS system is up and live, and the models make sense in context of each other, we need to add the appropriate tests to make sure we're not breaking anything in "production". This includes:

• Unit tests (for models, services, jobs, basic cases) that focus on independent single object tests.
• Integration tests (for end-to-end flow verifying that separate parts of the system work correctly in unison)
• Component tests

Should we create a resiliency matrix? Add regression testing?

Note*: This is neither part of the required design patterns nor the distinguishing features and thus should only be implemented once ALL the other mandatory requirements are complete to the highest degree.

Using heroku, which seems to be the most common Rails deployment software, we can deploy a live version of our Course Management System and release it to the world!

This is a significant part of our project (worth 15%) and thus should be composed carefully, thoroughly documented, and encompassed properly in one large PR. The use case of either of these three design patterns will need to be properly justified and all team members should contribute to the implementation and code design of the work.

See #4

This is a significant part of our project (worth 15%) and thus should be composed carefully, thoroughly documented, and encompassed properly in one large PR. The use case of either of the two patterns will need to be properly justified and all team members should contribute to the implementation and code design of the work.

See #4

This is a significant part of our project (worth 10%) and thus should be composed carefully, thoroughly documented, and encompassed properly in one large PR. The use case of this pattern will need to be properly justified and all team members should contribute to the implementation and code design of the work.

See #4

Ongoing issue to track the statuses of our weekly reports. See the updates Google Doc for more detailed information.

In order for TAs to better grade, tophat, and test our assignment, we need to add detailed tophatting instructions in the repo README on how to install dependencies, run the server, seed the database, tophat the full CMS flow, and execute the test suite.

This is just one example of the things we can do to improve the repo documentation.

Create a working basic UI through erb that implements the basic functionality of our CMS system.

• Implement sessions and user login (#30)
• Add registration and admin approval / request (#37)
• Add course creation and deletion functionality (#38)
• Add better modals for views and basic course search (#38)
• Add course registering and teacher admin approval functionality (#39)
• Add deliverables creation and activity upload for teachers

Do we need to tag in the commits or can we simply add the GitHub labels and tags to simplify commit messages.

Hey.

This is really cool. Rails makes me feel weird though. Please rewrite this in C.

Thank you!

From our first architectural meeting on Thursday, March 4th, we created a basic architectural design that fleshed out the main models part of our Course Management System (CMS).

We should use the Rails model generators to add these all appropriately to our project with the correct attributes. Exclude associations for now (all references) since that will complicate things. We can add those later as part of a separate issue.

See: https://docs.google.com/document/d/1B5f-h_zP56FkzmxSvfjoION5ufHEaIcShh16jMQkvx0/edit

This step is initially estimated to have a short time for completion since it only involves an investigation and analysis of how we can implement the required and non-required design patterns through our project.

This step involves NO CODE

TODO

• Figure out how to implement strategy/decorator/composite pattern
• Figure out how to implement factory pattern
• Figure out how to implement visitor pattern
• Figure out at least 3 more design patterns we can potentially implement through our CMS (Too much for this one issue - will open a new issue for this)
• Figure out how to implement observer pattern

ex.

Planned implementation for the Strategy pattern:

The Strategy pattern will be used for each of the user access permissions for the Student, Teacher, and Admin user types. Each of the user types will implement a type of behaviour (pulling it out from inheritance) and have their available actions composed with the class so that they can use the behaviour appropriately.

Planned implementation for the Factory pattern:

The factory pattern will be used in the following 4 cases:

1. A UserFactory to create the Teacher/Student/Admin.
2. A DeliverableFactory to create the Tutorial/Quiz/Assignment/BackgroundSurvey
3. A NotificationFactory to create the EmailNotification/WebNotification

Planned implementation for the Visitor pattern:

The Visitor pattern will be used on student registration, deregistration, and removal of courses. On the students course selection page, they should be able to bulk select a group of courses to perform a grouped action on (i.e. submit a Registration request for them, cancel the Registration request, or drop the course). Using the Visitor pattern, we can perform a corresponding operation on all of these Registration requests without changing the actual Registration class on which it operates.

Planned implementation for the Observer pattern:

The per class announcements will be our Subject with each of the course students / professors / teaching assistants being the Observers. If a user chooses the option to be notified of all announcements, they will get emails and/or web notifications appropriately which should appear clearly in the UI.

Once we've figured out the basic models relevant to our Course Management System and created the models/tables, we need to find a way to create their interrelationships.

For example, how should be implement the has_many polymorphic association between students and courses. A Student has many courses and a Course has many students.

In order to have a good demo prior to demo day on the 14th, we need to add rake seed tasks to properly seed our database with sufficient sample data so that we can demonstrate that the functionality works in our CMS without having to go through extensive user generation.

This creational step should include but not be limited to creating students, teachers, admins, deliverables, courses, departments, etc... (i.e. a good number of ALL objects).

We can look into the Faker gem for fake data generation.

• Seed task v1 implemented in #37
• Additional seed tasks (v2) added in #38
• Generate at least 10 users, 10 courses, 5 teachers, 3 admins (#46 )
• Use Faker for faking data generation (#46 )

This is a significant part of our project (worth 10%) and thus should be composed carefully, thoroughly documented, and encompassed properly in one large PR. The use case of this pattern will need to be properly justified and all team members should contribute to the implementation and code design of the work.

See #4

One of the distinguishing feature requirements is to make use of a database. Rails 6 by default comes in with support for sqlite3, a lightweight serverless database application so this requirement is already complete built-in. ❤️ Rails

We should use PlantUML or another modelling software to generate class and model diagrams for our project. In later weekly reports, these will need to be included as part of the updates.

Now that we sorta know what each model represents and have a better understanding of their attributes, we need to add a set of basic unit tests to validate some basic field presence and other appropriate checks

This part can only be done well once the logic of the Course Management System is fully fleshed out and we have confidence that our system will be resilient to change over the long term. Only then can we build our UI, which will be entirely composed of HTML and erb partials, to keep things simple.

We're avoiding GraphQL and React since that adds an additional layer of complexity not required by the assignment.

• Add bootstrap for much cleaner vanilla layout (#35)
• Add nice notice for info and error popups (#37)
• Add modals, styling, and popup functionality (#38)
• Add warning functionality on delete actions
• Add responsive UI with logical navigation and complete user flows

Reviewing work as the repo grows from more features are implemented top hatting instructions could streamline review process. Ideal for a PR description to contain all the context/instructions necessary for a reviewer.

Group Deliverables

• Submit final report
• Submit demo video

Individual Deliverables

• Submit individual video

This is less of an issue and more of an evergreen checklist of implemented security features as we go along creating our CMS.

• Implemented bcrypt, has_secure_password and password_digest encryption through (#30 )
  • This PR above implements the bcrypt password-hashing function that makes use of a salt to prevent rainbow table attacks. This is an up-to-date algorithm that is still relied on by corporations like OpenBSD, Linux, etc.
  • bcrypt hashes are a string in the form $2b$[cost]$[22 character salt][31 character hash]
  • Once plaintext passwords are saved in the system on user registration, they will never be directly accessible on the user model again
• User sessions and pre-controller access callbacks (#30, #45)

• Observer class model and sequence diagram
• Propose a more detailed implementation for SDC

See #4 for more context.

We should select a couple more Design Patterns from the GOF book once the basic ones in the above issue have been completed.

The previous factory approach we used was the simple factory and thus did not fulfil the requirements of the project. This issue consists of two steps:

• Implement a working Abstract Factory pattern and hook it up with the Deliverable/Resource creating functionality in the front-end and seed tasks
• Document how the mapping of this relates to the pizza diagram

Now that we have a basic template for the Observer pattern, we need to hook this up with proper functionality to the front-end interface and actually implement it.