GSOC 2013/Student Application udinnet/Fin IS(466)

Contact Information

   Email Address: udithabnd@gmail.com
   Telephone: +94772315516
   Blog URL: http://www.pageshack.com/shacks/uditha
   Freenode IRC Nick: udinnet

Why do you want to work with the Fedora Project?

   I'm already a fedora contributor for about 3 years now. To me, Fedora Project is a wonderful place to learn, contribute and keep in contact with other cool project members. Also fedora project community seems the most successful Linux distro project which has nice and very solid community architecture.
  

Do you have any past involvement with the Fedora project or another open source project as a contributor?

As I said. I'm a long term contributor of Fedora project. More details of my work in fedora projcet can be found in my fedora profile Uditha Bandara Wijerathna. I was a contributor of Joomla Project as a Developer for Joomla 1.7. Currently I'm holding the position, Manager (Initiatives) FOSSUser Project in Sri Lanka.

Did you participate with the past GSoC programs, if so which years, which organizations?

-No- This is my first participation. Its a pleasure to be a part of Fedora Project on GSoC 2013

Will you continue contributing/ supporting the Fedora project after the GSoC 2012 program, if yes, which team(s), you are interested with?

As always, I was an active contributor and I'll. Currently I'm a member of Ambassadors, Fedora Bugs, Freemedia groups. Soon I'll be contributing to the Infrastructure, Packaging and Kernel team too. Additionally I'll contribute continuously to the GSoC 2013 project that I'll be working on.

Why should we choose you over other applicants?

For the project I chose to work in GSoC 2013 is basically related to the Ambassadors and FAmSCO within the fedora project. I already have a thorough idea and hands on experience with Fedora Financial activities. Also I'm in contract with most of the person who handles the comm-arch and finance in Fedora. Finally I'm a hard working person and I try my best to achieve the targets in a productive manner. So I believe that I already have clean set of resources to implement this project and complete it successfully.

Proposal Description

An overview of your proposal

In the financial perspective, fedora project can be categorized in to “non-profit organizations”. So it'll be good to have an internal finance system for Fedora Project to handle the budget and transactions in a detailed and very transparent way. Normally Fedora project community plans the budget for an upcoming fiscal year containing four quarters as below.

March - May (Q1) June - August (Q2) September - November (Q3) December - February (Q4)

And after the budget planning is finished, Red Hat, the sponsor of the Fedora Project will allocate funding to the particular budget. Basically this with done by OSAS team and FPL. But there aren't any transaction recording and accounting system at the moment within the fedora project. So my plan is to develop a system that practices the well known double entry system and generate customized reports about the transaction details which are done within the project. customized to integrate with the fedora project's budget and funding routine.

The need you believe it fulfills

   Users will have the facility to login to the system using FAS credentials. So there will be no need to create separate accounts for the system.

   As for the current process, the people who manage the budget within the project will only record their budget plan detailed expenses in the wiki. The funding, reimbursement process will done via the regional,famsco trac instances ,etc. There will be no transaction records within the project. But with this system, the details of a transaction (reimbursement, ticket purchase, etc) can be recorded in the db and the financial state of the organization will be automatically updated through the accounting process.

   An authorized user or an authorized API call can generate report from the system about the current finance state of the Organization in any given time.

   Configurable currency convention options for individual tickets.

   Attractive UI

Any relevant experience you have

I have relevant experience in the area which this project implements in.

   I have development experience with General PHP, Joomla, Moodle.

1. Developer, PageShack.com

A Joomla 1.5 project which is highly customized incorporating with K2 component, newly designed login mechanism and user private front end control panel. The CMS is forced on user created blogs, supplying large amount of tool to handle their blogs.

2. Developer, Flick&Post

A photo sharing web app developed from scratch. It contain various advance features those a modern Photo sharing CMS has.

3. Team Leader, Web Development Team, Rajarata University of Sri Lanka. Developed a PHP & MySQL based back-end to the current Faculty website. Currently developing the front-end of the Main university website and faculty website.

   I have experience in web-services including WSO2 web-services open-source products. Apache Axis and Axis2. Also I've visited the WSO2 2011 and 2013 conferences with tutorial sessions, which are almost 100% about web-services.

How you intend to implement your proposal

Most of in this project will be implemented within CakePHP, an opensource PHP MVC Developement Framework. Login system will basically use the FAS JSON interface and there will be separate user role mapping within the system itself to handle the permission hierarchy. Because it is not possible to use the three roles that comes out of the box with FAS.

[role_type] => user,sponsor or admin

So what system does is, it check whether the FAS account is active and valid, then proceed to the next step which is mapping user in to the system db user details. If the user already (FAS name) in the table system go ahead and apply the role specific features. But if the user doesn't available in the system db, system will create a record automatically with the lowest privileged level.

System will use a basic element called a ticket as a commercial document (electronic) and the ticket will go through a process till it get funded. Meanwhile the accounting system will log the transaction records in to the db and update relevant accounts. The accounting system will practice the standard accounting principals. There will be a configurable settings to apply accounting principals (debit, credit) in to various types of accounts which will be using in system. Also users will be able to change the currency preference in the tickets , reports to their home currency and Google currency API will be used to convert the particular figures accurately.

The reporting component of the system will deliver reports as requested. That mean the output of a report request can be customized through various filters. The reporting component will be accessed via a RESTFul API and the system itself will utilize that inbuilt API for the report request from logged in users. The API will be implemented as authenticating required API. So that not everyone can view reports.

A rough timeline for your progress

1. May 21 -Refer CakePHP API Documentation

1. June 4 -Refine the idea about the system and clear up the problematic points.

1. June 16 - Prepare the database, Develop accounting system in according to accounting concepts. Setup account type per-configuration.

1. June 30 – Hack CakePHP to integrate with FAS JSON auth interface. Development of login mechanism with internal roles. Defining the boundaries those each role spreads.

1. July 7- Develop the ticketing based component, Define ticket states and their mapping in to the db. Design UI for the back-end, enhance forms with AJAX.

1. July 21 – Get ready for the mid evaluation, Test the mechanisms, Write documentation, Refine the code.

1. August 2 – Defining Reporting filters and reporting output mechanisms. Develop simple RESTful API to access the reporting features.

1. August 16 – Design Front-end UI, Integrate front-end with core system.

1. August 23 – Enhance the reporting API, Debug, Test the system.
2. August 30 – Develop the currency convention feature using the Google currency converter API. Integrate ticket system with the converter. Enhance the core accounting system.

1. August 6 – Test the full system functionality, Finalizing the code of the system
2. August 10 – Final debugging and preparation of the system for packaging, Packaging the system.