Introduction

This document contains information regarding the progress and details of the Google Code-In with New Architecture project (GSOC 2011).


Design and Implementation

Converting roles and updating references

Minor changes have to be made to the GCI models such that fields that refer to student/org_admin/mentor should now refer to profile as we are getting rid of Mentor/OrgAdmin entities and Students are defined by their StudentInfo coupled to the profile.

Implementation

  • A GCIProfile model will be written which extends soc.models.role.profile and the GCI specific fields are added to this model and the GCIStudentInfo model which is coupled to the student's profile.
  • If someone is both OrgAdmin and Mentor for the same organization, then we will not need to update the GCIProfile with mentor information (mentor_for field).We assume that an org admin is also a mentor.
  • The GCIProfile model contains the GCI specific notification settings.
    • Currently, GCI has a different notification system where a user X can subscribe to the notification to a particular task by clicking a star on the task and can un-subscribe the task by clicking on the same star again, org_admin,mentor and the student claiming are automatically subscribed.
    • In addition to this, we will now have Profile based notification settings where a user will be given an option to whether subscribe for the notifications automatically or not, for example a student at the time of profile creation can check/uncheck automatically subscribe to tasks I claim.The same can be applied for mentor and org_admin.
  • The GCIStudentInfo model contains additional fields specific to GCI
    • number_of_tasks_completed -> contains number of tasks completed by the student
    • consent_form -> A signed Parental consent form
    • student_id_form -> Student ID to verify a student
    • grade -> The grade in which the student is
  • We then write a script to convert the roles itself.Basically for each student,mentor or org_admin entity we create a GCIProfile.And then we update all these references in the models containing them.we will use the deferred library which lets us retrieve entites in batches and update their references easily.

Move list generator to the core

As the list generator is required even for the GCI module, we move the list generatorfrom gsoc module to the core.

Implementation

  • Move gsoc.views.helper.lists to soc.views.lists and fix the corresponding imports

Request-Data Object

A RequestData object that will be created for each request in the GCI module will be written.This extends the soc.views.helper.request_data.RequestData and GCI specific data is added to it.

Implementation

  • The GCI RequestData object contains the following fields
    • site: The Site entity
    • user: The user entity (if logged in)
    • program: The GCI program entity that the request is pointing to
    • program_timeline: The GCITimeline entity
    • timeline: A TimelineHelper entity
    • is_host: is the current user a host of the program
    • is_mentor: is the current user a mentor in the program
    • is_student: is the current user a student in the program
    • is_org_admin: is the current user an org admin in the program
    • org_map: map of retrieved organizations
    • org_admin_for: the organizations the current user is an admin for
    • mentor_for: the organizations the current user is a mentor for
    • student_info: the StudentInfo for the current user and program
  • The RequestData object contains methods like,
    • getOrganization: To get the specified organization
    • orgAdminFor: Tells if the user is Admin for the specified Organization
    • mentorFor: Tells if the user is Mentor for the specified Organization
    • appliedTo: Tells if the user has applied to a specified organization
    • isPossibleMentorForTask : Checks if the user is possible mentor for the task in the data
    • hasCompletedTask : Checks if the user has completed atleast one Task
    • currentTaskState: Returns the user's current task state
    • populate: To populate the fields in the RequestData object

Access checker specific to GCI

An access checker class that contains helper functions for checking access in the GCI module.

Implementation

  • Add the required objects to Mutator class to mutate the data object as requested, for example
from soc.modules.gci.models.task import 

class Mutator(object):
  # unset the data object first  
  def unSetAll(self):  
    self.data.task = unset 
  
  #kwargs which define a Task
  def taskFromKwargs(self):
    id = int(self.data.kwargs['id'])
    self.data.task = GCITask.get_by_id(id, parent=self.data.profile) 
* After finishing with the mutator class, we can have access checker methods like,
  * isTaskInURLValid -> Checks if task in URL exists
  * canStudentClaimTask -> Checks if the student can claim a Task.

URL Patterns

The GCI related URL Patterns should be created, they will be discussed in the implementation.

Implementation

  • The patterns will be returned in any of the following ways
    • namedLinkIdPattern -> Returns a link ID pattern consisting of named parts
    • namedIdBasedPattern -> Returns a url pattern consisting of named parts whose last element is a numeric id
    • namedKeyBasedPattern -> Returns a url pattern consisting of named parts whose last element is a string representation of a Key instance

Redirects

A helper view for constructing GCI related redirects which can be used in other views for redirecting.

Implementation

  • A RedirectHelper class will be written for constructing required redirects.
  • Here we set args/kwargs for a url_pattern.<TYPE> redirect, where TYPE can be organisation, profile,document etc
    • For example,
self.kwargs['survey'] = survey
  • Other methods that help redirects will be.
    • urlOf -> Returns the resolved url for a name
    • url -> Returns url of current state
    • to -> Redirects to resolved url for name
  • specific methods to set the _url/_url_name for particular redirects
    • For example,
def homepage(self):
  self.program()
  self._url_name = 'gci_homepage'
  return self

Site Menus

For now, the views for the site menus can be similar to that of the GSoC site menus with certain minor changes.

Required Views

The following are the basic views required, This section will be updated as the views are written.

  • Public Task view
  • Task subscription
  • Work submission
  • Program settings view
  • Profile
  • Admin
  • Org application
  • Org Profile
  • Org Homepage
  • Dashboard
  • Document
  • Assign Mentor
  • Student Ranking

Implementation

  • All the views will be basically have the following
    • djangoURLPatterns -> To return required url pattern for the view
    • checkAccess -> To check if a user has access to this view
    • templatePath -> Returns the path to the template to be rendered
    • context -> Returns the current context of the view
  • A view will have other required methods specific to that view.

Meetings and Agendas

Tuesday, May 17:10:00 in UTC

Meeting Notes

Location : Skype
Time : Tuesday, May 17:10:00 in UTC
Conducted by: Lennard de Rijk, Madhusudan C.S
Notes taken by : Selwyn Jacob

  • General Discussion on the approach to start the project.
    • Change the GCI models such that the fields that refer to student/org admin/mentor should now refer to Profile as we are getting rid of Mentor/OrgAdmin entities and Students are defined by their StudentInfo coupled to the profile.And use mapreduce or Task API to go over all entities in GCI that need to have their reference updated.
    • Move the List generating module from gsoc.views.helper to soc.views and change corresponding imports as even GCI needs this.
    • Create GCI specific RequestHandler and RequestData object created for each request in GCI before starting with writing the views.
    • Start with the dashboard functionality.