Hanson

Status:

Small part of this week spent working on the RoR tutorial

Most of this week working on issue 404 (remote tags). Managed to get out a review for form_remote_tag (only 1 instance is not blocked right now). However the majority of work will probably be in link_to_remote as there are 30 instances the last time I checked. I’m going to split up the commits so they are not all mashed into a single commit.

Roadblocks:

Took quite some time to figure out how to convert to form_tag for the page I was working on, because it used unobtrusive javascript to handle the ajax request and response.

Didn’t realize that the groups page actions were already broken (due to routing I believe, issue 602), and thought I was doing something incorrect.

Next Steps:

Continue to work and debug the remaining remote tags for issue 404.

Aaron

Status:

Had a blocking issue over the weekend with mysql gem, for some reason after fetching the most recent updates from markus-upstream, my whole rails framework completely forgot about mysql gem, which did not let anything run

Tried troubleshooting with tobi and erop, but to no avail, now have decided to move forward with using sqlite3 as the db adapter

Rails framework is back up for me and I am continuing on my progress on issue 298

Roadblocks:

None currently

Next steps:

Continue on getting issue 298 into review state

Pick up a rails 3 bug to work on by the end of the week

Continue progress on RoR tutorial

Christine

Status:

Following some advice from Egor, did CookieDetection from login method in main_controller.rb instead of application_controller.rb, so that cookies are only checked at the login screen because users with cookies off are redirected to login screen.

Successfully displayed “Please configure your browser to accept cookies.” message using flash[:login_notice] when cookies are off at the login screen. This message is defined as cookies_off in en.yml, will need help translating this for fr.yml.

Sky

Digging deep into code to revise my review of issue#320 (need examine and discuss more about the meaning of grace credit display and how the data is stored)

Fixing and testing the code for issue#402 (142 changes need to be made and tested)

Roadblocks:

None

Next Steps:

Submit and ship issue#320 and issue#402

Pick a new issue if smooth

Danesh

Status:

Administration of various reviews and issues – marking as submitted/closed.

Dug into #441, found a solution for collecting submissions. It was marked as a duplicate of #500, the comments there say the lack of redirect to the results page is a separate issue so I submitted a review for just collecting submissions.

Claimed and started #475 – replacing legacy prototype code. Working my way through the codebase and finding and replacing all deprecated code with the functional implementation.

Next Step:

Finish off #441 – Severin asked that I write a test for it so I’m doing that next.

Continue with #475 – check what the devs want me to do with the more complicated functions that aren’t one-line substitutions.

Reviews!

Potentially another bug?

Roadblocks:

Terrible wifi on megabus! Fortunately had access to IRC and wget 😀

Tobi

Status:

Fixed issue 468

Worked on 434 which turned out to be a duplicate of 607 and Egor has a fix for it

Currently working on 641, 603 and 581

Spent time helping Jay out with an issue

Worked on adding the Mac OS X installation instructions

Roadblocks:

Studying some Prototype Javascript tutorials to fix 641

Next Steps:

Closing 641, 603 and 581

Jay

Status:

Continue to investigate on issues 620 and 602. It took a while to figure out the auto generated _path url for one of the broken links and with Tobi’s help, I am one step closer to fixing it.

Ran into some git issues with Markus wiki so haven’t been able to update it yet.

Roadblocks:

None.

Next Steps:

Close issues 620 and 602.

Update Markus wiki.

Sean

Status:

Spent a lot of time working on ruby tutorials, some javaskript, and getting familiar with the MarkUs code

Met with Jay and Aimen to talk about the current issues we are all working on, and how to proceed

Finished working on an implementation of issue # 617, but it has not yet been posted for review.

Danesh is currently testing the API but is a bit confused about the way that Severin tested some other API. He has been struggling with understanding shoulda functions. He also wrote a blog post containing information on the API for managing users. He would also get the information on his blog post up on the wiki.

Misa is currently waiting her review to pass.

Karen was wondering if the remark requests feature was ready to be demoed at Research In Action (RIA) showcase at the University of Toronto. However, the review request for the feature had not passed yet. Severin and Misa intend to coordinate to get the remark request feature up and running for the RIA demo.

Karel just finished classes and would be able to put in more time into Markus now. He is currently working on the functionality of deleting items and would get it done by the end of the week.

Bertan put up a review today and he is waiting for responses. Meanwhile he would be writing tests for the feature.

Tobi has been able to create a modal dialog for role switching. However, he has a problem with loading the index page of the user whom the admin is trying to assume the role of. The problem is with AJAX requests. He intends to fix the problem by tonight and would also finalize tests for the feature.

Ibrahim just finished fixing a bug in the annotation categories drag and drop. He would also be writing tests.

The UCOSP steering committee will be meeting next week to sort out most of the marks and other stuff, so Karen would like everyone to send her a note before the end of the week.

Here is the UI for Role Switching that I developed. I made the design to be similar to that of the login screen though there were some changes. The changes I made was just so that the UI for role switching is not confused for that of logging in.

The option to switch roles added for admins to the top right of the screen

The UI for role switching added to the right of the screen

The view of the UI in the browser

The screen displayed after the admin with first name “admin” switches role to student c5anthei

Error Messages:

The error messages are a mirror of the ones for login

Error message displayed when user name and password fields are blank

The password field was blank

The user name was invalid

Input about the quality of the work and some error cases that I might not have considered will be appreciated.

The role switching feature will give administrators the ability to assume roles of students or graders and view their profiles exactly as it will be seen by these users.

-Administrators will have the privilege of editing and modifying student and grader profiles.

-Administrators cannot assume the role of different admin users

-Administrators will have to type their password to be authenticated before they can switch either from their role to one with “lesser privileges” (student, grader) or from a role with “lesser privileges” back to their original role. This is to ensure security.

-The actions that administrators carried out on assuming other roles should be logged

IMPLEMENTATION

With help from Severin’s previous post on role switching implementation, here my proposed solution

Main terms are real_user and effective_user. real_user stands for the original administrator who is assuming the role of some other user. effective_user represents the user that the administrator is currently logged in as (this field could either represent the admin, grader or student).

Implementation Ideas And Code:

1 Add fields “real_user” and “effective_user” to the user model. Both fields are nil by default.

Code: To be added

2 Modify the “current_user” method (lib/session_handler.rb) so that it returns the id of field of “effective_user” if it is not nil.

Code: To be added

3 Modify the logout/currently logged in user area so that it shows the “real_user” as logged in user and the “effective_user” as the assumed user including a link (call it “exit role”, for example) which allows admins to become their “real_user” again. Current logout link stays as is.

Code: To be added

4 Add views (possibly modal dialogs) and according controllers for role assumption and password prompts prior leaving the “real_user” role and right before getting back to it.

Code: To be added

5 Modify the logout controller to erase “real_user” and “effective_user” should they be set.

These days I am trying to do some coding on showing TA’s marking distribution. But I find that after reading through part of our codebase carefully I got more questions than ideas about the implementation. So I decide to post this blog listing all my thinkings so far and seeking for help from yours 😉

The first thing that troubled me a lot is the various types of Active Record associations 🙁 Fortunately, by reading this page http://guides.rubyonrails.org/association_basics.html I’ve got some basic understandings about all these “belongs_to”, “has_one”, “has_many”, “has_many :through” and so on. Then by reading this graph https://github.com/MarkUsProject/Markus/wiki/database_20101001.png I got a general idea about how our database works but it’s still not very clear. I need some more help to understand the relationships between these models, especially:
* Assignment
* Submission
* Result
* Mark
* Grouping
* Group
Basically, on the topmost level I want to find some relationships between the *result of each submission of an assignment* and *the TA who gives this mark*. Although I know the meaning of these “belongs_to”, “has_one”, “has_many”, “has_many :through” and so on, I got stuck when I want to use these associations between Active Record models to get what I want. So, anybody help? 😉

Above are all my thinkings about the associations between our models, and then I want to talk something about the results_controller.rb.

I think the edit method is where the TA gives a mark to a submission, also I’m not quite understand how these two methods work which are set_released_to_students and update_mark. I believe fully understand these three methods will help me a lot on my task, so can anyone help me here? 🙂

Moreover I see in the results_controller.rb the method current_user which is defined in app/helpers/main_helper.rb is called in many places. Basically, the major thing I want to do in the results_controller.rb is collect the data about which TA gives what mark to a submission of an assignment. I think results_controller.rb is the best place where I can get all these factors at the same time. The idea is I can get the user_id of the TA by calling current_user and get the submission and assignment in the similar way in the edit method (line 24 to 27 in results_controller.rb). Although I see the edit method (line 47) set the mark, I got a question about how I can get the mark of a submission?

I don’t know whether my thinkings above are exactly right. But assuming they are right and suppose I have got all these things I want in hand. The next thing I want to do is construct a data structure to store these information. For now the best way I can figure out is introduce a hash as a member variable for the assignment model which keep the submission_id as keys and ta_id with corresponding marks as values. I don’t know whether it’s a proper way to do this and I have no idea where should I construct this hash. Should I introduce a new model like assignment_stat or just do it in the assignment_stat model or define a new method in the results_controller.rb to collect these information in the hash? I’m looking forward for some comments on this and really appreciate for your helps 🙂

This term I (Yansong) will improve the dashboard feature. Currently, the Bluff Graph on Dashboard can only show the whole grade distribution of an assignment but we also want to see each TA’s distribution. Also the table on the right of the graph only shows some basic information of the assignment and simply lists all the TAs’ names who mark this assignment, but we want to show some detail information about the assignment and each TA.

It seems there will be several missions to to. Basically, this blog lists what I think so far should be added to our dashboard in order of priority.

* Show each TA’s grade distribution vs. the whole distribution in the graph.
* Show each TA’s marking progress in terms of “total # of submissions/# of completed” in the table.
* Show each TA’s average mark in the table.
* Show both the total and average number of annotations given by each TA.
* Show more statistical information about an assignment and each TA such as MIN-MAX marks, Standard Deviation and Median

Bryan and I work closely to refactor the whole project to adopt our new design. But at the mean time, we found that we may not finish the whole refactoring before the end of the term since it pretty much requires a full refactoring for all files (not really all but quite a lot). We prepared a document to present our design principle and refactoring plan for future reference and as well as to make sure we don’t go extreme *wrong”. 😛

I wrote this rough draft to present the basic ideas. It might not be detailed enough however it does show the critical points of the new design. We will revise it pretty soon.

Please feel free to ask questions and make suggestions regarding the new design.

I played around with railroad and created a class diagram for Markus’ models. It shows clearer relationships between models compared to the db schema diagram. Showing methods in a class diagram will be useful, but I’m not sure how to do that using railroad.