Connection Demo

I spent my development time this week working on a demo implementation of the connection strategy, utilizing existing code in gsoc/views/invite.py and request.py for simplicity's sake. I'm going to spend the next couple of weeks cleaning everything up and, as mentioned in my previous post, consider the option of replacing request.py and invite.py with connection.py. This option is seeming more and more appealing as I move on since (as previously mentioned) it doesn't matter who initiated the connection, only that one exists. There is no distinction between a request and an invitation, so I don't see basis for separating them. I know that there are a lot of things I need to fix before I actually submit everything to the main repo and I've made note of them; the goal of this week was merely to get a working replacement of GSoCRequest with GSoCConnection up and running. I'm using pastebin here and haven't committed anything to a branch of the main repo to save myself revisions while I'm finishing up the demo.

A lot of what I've done is simplify the logic of the two modules to use GSoCConnection rather than GSoCRequest - nothing too elaborate yet. Here's a snippet from request.py, which handles the POST request when a User requests to become a mentor for a particular organization. It generates a GSoCConnection instance between the User and the organization properly and forwards the user onto the view_request page (which I'm going to replace later). I've made changes to the checkAccess() and context() methods to facilitate this change, though the latter isn't done yet. Here's the post snippet from invite.py, again context() is still in progress.

One big hangup I've run into is the dashboard presentation and query of these connections. I tried changing a few columns of the ListConfiguration in the __init__() method of my ConnectionComponent class only to find that the table no longer displayed. That said, I dug into the ListConfiguration class and then rewrote the init method to fit my needs (discovering the Python lambda functions in the process, which are fantastic). However, I'm stumped on the following query in the getListData() method:

q = GSoCConnection.all()

 if self.for_admin:

      q.filter('organization IN', self.data.org_admin_for)

 else:

      q.filter('user =', self.data.user)

No matter what I do I cannot seem to get any Organization or User objects to equate or match in this query, even when I know that there are valid objects meeting the criteria in the datastore. I've used the logging module extensively to try to get to the root of the problem but am at a loss as to what I need to do to fix it. Other than that, this week has been an excellent learning experience and I feel far more comfortable with the view system and the lifecycle of a RequestHandler subclass, which will be useful when building the connection module.

GSoC 2012 Extension and Integration with External APIs

Sorry for not being able to stay connected with and work for the community last week first of all
owing to some health issues. I could not do much work.I started out with creating a new local branch out of the current master branch and integrated first three changes of shipmenttracking branch viz.  Add task for syncing shipment tracking data[0], Implement the shipment tracking admin views for setting the document to sync [1] and Add the modules necessary for shipment tracking [2] and it works well.


[0]http://code.google.com/p/soc/source/detail?r=179cdc3d628ac637928e1adcb26c581692465055&name=shipmenttracking
[1]http://code.google.com/p/soc/source/detail?r=c18d34cd83e8f282931813c26d6abf1246a389bf&name=shipmenttracking
[2]http://code.google.com/p/soc/source/detail?r=a5dfbf735e3852bb37d98748428be56844783331&name=shipmenttracking

Design & Finalized GSoCConnection

I have spent this week coming up with notes on the current request and invite modules' structure (not actual logic) in order to better understand how I should go about changing the actual functionality. I have decided to keep the generic configuration methods within these modules for the time being so that I can spend most of my time working on the logic; methods like djangoURLPatterns, templatePath, and probably checkAccess will remain the same while I'm doing some basic work. Later I will likely change these to allow for a more dynamic workflow. To quote daniel, I'll try to move away from the request -> org response and invite -> user response since it's not going to matter which party initiates the connection. I believe I'll be combining this functionality into one module (most likely views/connection.py) as I progress, but for next week I'm going to keep everything in the current request/invite design and use the current UI.

This week's goal is to develop a working demo with sample connections utilizing the new GSoCConnection model I wrote last week and finalized over the weekend. We've cleaned it up and simplified the states that it can represent slightly so that there isn't any distinction between an accepted mentor invitation and an accepted mentor request; if necessary, the type of connection will be signified by the party who initiated the connection.

The only code I have for you this week is the finalized GSoCConnection model (linked above), but next week will  be more interesting once I've completed the request and invite demos.

Melange Functional Testing

This week i worked on completing all the three test test scripts and making changes to base module melange_functional_actions.py. I sent my first patch to melange this week. All the test scripts import this base module and use it in writing functional tests. I am waiting for the base module to get committed so that i can start sending test scripts. I am making changes continuously to the base module adding more and more functionality to it so that test scripts look more clean. I have completed three test cases till now. One such test case is TC01 student_registration_test_tc01.py where we are checking the student registration process, when a student enters all the correct details and successfully register himself/herself on melange. Test Case , Steps to Execute, Check Item, Test Case Objective and Expected result are shown below.

Test data for all the test cases will be imported from the sheets of testdata_melange.xls workbook.
 

Here TC01 sheet contains the data for Test Case with id TC01, similarly TC02 and TC03 sheets contains test data for TC02 and TC03 test cases. The details of TC02 and TC03 will be filled in functional test cases spread sheet. The code for other two test scripts can be seen here.
Apart from this i made changes to the names of different methods in Base Module and added a couple of more methods to it.

GSoc 2012: Extension and Integration with External APIs: Week2

Hi 

It has been a week now since the coding period started and I have not

done much work yet, I was spending time with Javascript and jQuery basics.

This week Me, Madhusudan and Mario scheduled  meeting to discuss over
the strategy to integrate present Orcun's code (extended by Madhusudan)

to integrate with melange. Since during the year lot of code has been
pushed to melange I will require to work on merging conflicts and then

look at what the outcomes are in terms of functionality before merging.

Madhusudan has already shared the patches and the  git branch

shipmenttracking for me to work on. This week I will apply patches 

to current melange codebase and will do the  necessary changes to 

make it compatible with Melange.

Initial Connection Model Implementation

Hey all, this week I've been discussing the requirements and details of the model that I'm going to be using to represent both invitations and requests between an organization and a user. We've decided on using a model called GSoCConnection containing reference properties to the organization and the user involved in the request or invitation. Within this model also resides "private" properties to represent the actions taken by either a user or an organization. For example, a user sending a request to become a mentor will cause the user state to become 'mentor_request_accepted' and the org's state to become 'mentor_request_pending', since we'll be waiting on a response. If the org accepts, their action will be changed to 'mentor_request_accepted' and the calling class will be able to call the is_mutual_acceptance() method in order to determine whether the user needs to be promoted.

Right now I've thought up as many states as I think are relevant and added them to my GSoCConnection class as constants with methods to allow for changing the state. Another approach I've been toying with is just writing out methods for each of these to encapsulate some of the logic for determining the states and chaining them with an internal set_state method. I'm going to discuss this idea with Daniel this week and possibly discuss alternatives.

The code for my first implementation of this model can be found here (not the most elegant way to share code, I know). See you next week!

Update: Changed the pastebin link to reflect change to method names per style guide and changed my strategy for supporting states

Melange Functional Testing- Base Module & Test data

Hello everyone, This week i mainly focused on creating a base module Melange_functional_actions.py for the framework. In the base module i defined a base class funcTests which consists of many other methods which will will be used in creating test scripts for different scenarios. e.g:

1. get_parameters(name_of_workbook)
2. write_text_field()
3. wait()
4. toggle_checkbox()
5. set_dropdown_list()
6. wait_and_check_if_displayed()
7. wait_and_click()
8. wait_and_enter_text()
9. wait_and_clear_field()
10. assert_error()
11. assert_link()
12. click_on()
13. assert_text()
14. take_screenshot()
15. clear_field_and_enter_new_data()
16. setUp()
17. tearDown()
18. login()

I am using these methods to re write the test script for Student Registration Test . Student Registration Test has three test cases.

TC01 checks the normal path of registration.
TC02 checks for error messages when empty form is submitted.
TC03 checks for messages when wrong inputs are supplied to registration form, It assert all the messages and provide correct form data for successful registration.

Test data for the test script is here.