GSOC 2014/Student Application udinnet/FinIS

Contact Information

• Name : Uditha Bandara Wijerathna
• Email Address: udithabnd@gmail.com
• Telephone: +94772315516
• Blog URL: http://blog.uditha.org
• Freenode IRC Nick: udinnet

Why Fedora Project?

I've been a FLOSS lover since I started to learn computing. I helped various FLOSS initiatives in Sri Lanka and helped lot of people who try to start their computing life with linux operating system. I'm already a fedora contributor for about 3 years now. Also I'm a Linux user since 2005. In my Linux journey, I used and experienced lot of types of distros. 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.

Past involvement with Fedora Project/FLOSS

As I said. I'm a long term contributor of Fedora project. More details of my work in fedora project 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. I contributed to the FOSSUser Project as a speaker and technical writer. Furthermore I work closely with FLOSS fans in Sri Lanka to develop people's attention towards FLOSS, help them to raise up new initiatives and work in those.
• I'm one of the co-founders of LUG RUSL, The Linux User Group University of Rajarata. And I was able to release a fedora remix named Rajarata Linux using Fedora version 17. Rajarata Linux dirstro was built targeting mainly the CSE students who tends to develop applications in various types of programming languages and platforms.
• Currently I'm the webmaster and the maintainer of official Sri Lankan Fedora Community website.
• I have also given lot of tech talks in many conferences including, FUDCon KL 2012, FOSSASIA 2014 representing fedora.

Earlier participations of GSoC programmes

This is my second time participation in GSoC. My first time, I participated GSoC with Fedora Project.

Future contribution toward Fedora Project

As always, I was an active contributor and I'll. Currently I'm a member of Ambassadors, Fedora Bugs, Freemedia groups. My future contributions can be boiled down to below points.

• I already requested the membership of the Infrastructure team.
• I'm very much interested in Kernel Development area of Linux Kernel and I'm quite in a confident state about the Linux driver development. I already developed few simple USB drivers and continuing to enhance them. I'm planning to contribute to the Kernel team in the near future.
• I'm in a good standard on RPM packaging fist by reading the Fedora Packaging guidelines, packaging few simple test packages and then by adding some customized packages in to the Rajarata Linux. Furthermore I completed RH401 course on Red Hat Enterprise Deployment and Systems Management which has "building custom RPM packages for RHEL" in its syllabus. So I'm planning to submit few new packages for the review and contribute to the Packaging team.
• Of course, I'll continue contributing this Fin IS GSoC project after this summer by improving its features, etc.

Why choose me?

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. In addition to that,

• I'm quite good in PHP development. I already developed various from scratch PHP apps and Joomla customized projects.
• I'm already using GIT for various projects and have a thorough idea about how GIT works.
• I'm quick learner.

The Project Proposal

Proposal overview

How current Fedora finance process working

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)

In the financial perspective, fedora project can be categorized in to “non-profit organizations”. Basically there will be three main categories of funding in Fedora Project.

• Premier Fedora Events - Premier Fedora Events are events organized by the Fedora community that are all about Fedora. FUDCons and FADs are the two most common types of Premier Fedora Events.
• Regional support - The small fedora related events like Release parties, Linux events which are happening under the control of Regional Ambassadors teams will be covered under this category.
• Discretionary funds - The funds which are allocated at the discretion of the OSAS team in conjunction with the FPL, which chooses to make that line item of its larger budget transparent because most discretionary spending ends up being on Fedora.

The Budgeting Process

For each region, there will be an Ambassadors team consist of people from countries which are covered from that region. All the ambassadors regions are controlled by Fedora Ambassadors Steering Committee (FAmSCo) and main budget planning process for the whole project happens there. For an upcoming fiscal year there will be a projected budget from every ambassadors regions. In other words, there will be planned spendings for each and every region distributed across four quarters in a year. After the regional budget is prepared by regional budget wrangler or treasure combining each country budget, it'll be submitted to FAmSCo and OSAS. For example Budget page for

• APAC
• EMEA
• LATAM
• NA

After the budget planning is finished, Red Hat, the sponsor of the Fedora Project will allocate funding to the particular budget. Basically this will done by OSAS team and FPL. But there aren't any transaction recording and accounting systems at the moment within the fedora project.

Reimbursement of expenditure

A key point which must be considered in this project is the fund requesting and reimbursement process. Below are the different types of processes followed in different request types.

• For An regional event the process will be

1. Creating a wiki page about the event. There should be event owner(s).
2. Opening a ticket at particular regional trac
3. Approve the ticket by attending the regional meeting.
4. Upload receipts to the ticket and wait for reimbursement.

• For travel subsidies

1. Opening a ticket at particular regional trac at least month before the travel date.
2. Approve the ticket by attending the regional meeting.
3. Upload receipts to the ticket and wait for reimbursement.

• For other funding requests (This type of funding requests making is only allowed to fedora project contributors)

1. Opening a ticket at particular regional trac with the full detail of the fund request.
2. Approve the ticket by attending the regional meeting.
3. Upload receipts to the ticket and wait for reimbursement.

• In addition to these processes there will be funding processes for Premier Fedora Events according to the situation.

My Plan is to

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. 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.

As this is the continuation of the project which will first start with packaging CakePHP for fedora and then add some new features to current implementation.

The need it fulfils

• 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.

• A fully customizable accounting scheme which can be set up in the initiation of the project by whoever the person in-charge in accounting administration. From this, each an every account's behaviour can be pre planned.

• 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. So when it comes to public report preparation about the financial status of the Fedora project, it can be achieved through customized report generation API call.

• For the budgeting purpose for upcoming fiscal years, users will have the facility to create tickets(budget request tickets) for their country's upcoming events and other expenditure related fedora. Then from the reports admins will be able to project the upcoming budget by evaluating budget tickets on regional and country basis.

• Configurable currency convention options for individual tickets.

• Attractive UI

Relevant experience I have

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

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

• I'm a B.Sc ICT (Special) Undergraduate of University of Rajarata Sri Lanka. (Curriculum includes Mutimedia & Web Design, Internet Programming, Web Services, Management, Principles and Practices of Accounting modules)

• 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.

• Developer, Flick&Post

A photo sharing web app developed from scratch. It contain various

advance features those a modern Photo sharing CMS has.

• 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 participated the WSO2 2011 and 2013 conferences with tutorial sessions, which are almost 100% about web-services.

Implementation of the proposal

Top tire Architecture

• Below is the illustration of proposed top tire architecture.

• The definitions

• Illustration

Most of in this project will be implemented within CakePHP, an opensource PHP MVC Developement Framework. The reasons are to select CakePHP

• Very mature project.
• Uses the MIT licence (Which is compatible with GPL)
• Good community support.
• Very organized documentation.

The Login mechanism

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. The reason is the user need to be in a newly created group (something like fedora-financial) and bearing the role. But this will be big separate process including adding each and every contributor to a new group. Not only that, these roles are not intended to hold a responsibility which will be required by this financial system.

[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.

[image]

This has been already completed in GSoC 2013, But in this time GSoC login mechanism will be improved by adding FedOAuth that supports OpenID to the authentication objects.

The Ticket

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. It has states through out the lifetime. Ticket body can be defined and customized as per the need. Fields on the ticket can be added and joined in to compatible data sets in accounting component.

• Ex: Organization's budget committee (For fedora project its FAmSCo) need to tack separate spendings for SWAGs, Media, Refreshments for event sponsorships.

So the super user of the system can define,

SWAG cost will go to ==> A account

Media cost will got to ==> B account

Refreshment cost will go to ==> C account

In addition to that, the tickets will be always populated from the initial configuration and tickets can have different templates. The body of those can be defined. It can be configures not only the status alone run a rule but another parameter too.

This option is already implemented with ticket configurations. But need to fine tune some features of it.

Accounting (Double entry) mechanism

The super user can design the accounting system in double entry aspect. That means when the system configuring initially, super user can create account posting pattern for each and every state change in the ticketing system. So when system is running it check the rule at each and every state change and execute the rule debiting or crediting amount to noted accounts. That allows the system to perform more than two amount updates.

• Ex: When a ticket is approved, a rule executes and update 4 accounts, Debit - Approved Not paid account / Credit - FY2014 Allocated budget account/ Debit - 2014 Event sponsorship account / Credit - 2014 Event sponsorship budget account

Double entry mechanism has alredy been implemented with configuration features.

Currency Convention

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.

This implementation is pending.

Reports

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.

This implementation is half way through. Still need to implement the rest of the reporting API.

Significant features

• State changes tacking of tickets through accounts.

This feature is very useful when it gets to different states of tickets. As above illustration of ticket states and as mention in overview all the fund requests will be gone through a process. In the point of making the actual funding request(monetary) the requester will open the ticket. Then onwards the ticket state will be tracked papally from ticket's perspective and even from the accounting perspective. The advantage of the approach is that in the normal process, tickets will be there for a while (maybe one or two month(s)) and there should be a way to take a snapshot of current financial state of the organization even when some tickets are in a middle of a process.

• Can be used by any FLOSS organization

The development of this project is targeting not only Fedora Project but also any FLOSS organization that consist of a community. In a final phase of the implementation, the customization of the system in to the Fedora Project will be done in a top-level layer while not-touching the original code.

• Parallel Currency Recording

The concept behind here is basically related to accounting. There are transactions happening between two currencies where the request date and the reimburse date of a ticket will not be the same date in 99% of cases. If there was a change in currency rates within the dates of ticket creation and reimbursement, definitely one party (Org or contributor) has to tolerate the cost(or damage). Since the basic accounts will be prepared in US Dollars, this scenario will not affect to USA. As a solution, in this project I'll try to avoid this situation by maintaining parallel currency records in two fields of account tables when the ticket is being created using a currency other than US Dollars. So there is a way to setup a mechanism to calculate damage and decide a party who will tolerate the damage.

• Flexible Accounting configuration

In this system, I focused on giving the privilege on setting up the initial configuration of debits/credits of the accounts in state transitions to the accounting administrative person in the system. So that he/she can decide the accounting format for their FLOSS organization. Because all the FLOSS organizations not behave in the same way when it comes to financials.

• Customized reports

As stated in above, the reporting component will provide an API to request reports. Report can be generated according to the request attributes. For the moment, the planned attributes are,

• Report type (Account summary/Balance sheet)
• Date range (Specific/Quarter/Year)
• User (individual accounts)

Also super users can decide what kind of report with what kind of information should be generated. Simply super users can design their reports with out touching the code but through using the API.

• The Security

Since this system carries out sensitive data, it should be well secured against attacks. This system will be having the following security features.

• Cross-site request forgery (CRSF) protection.

The CSRF token is generated for each request, and each token can only be used one. If a token is used twice, it will be blackholed.

• Forced SSL

For the back-end actions of the system, It'll be under SSL.

• Form tampering protection

When there is a form submission, Hidden token fields will automatically be inserted into forms and checked.

• User role definition

Admins can add security permissions specifically into user roles and users

• Email notification

Every important action will be notified via email to action initiator and sometimes affected parties

Ex:- Admin "Bob" add user "Nishmi" APAC fund request approval privilege. Then both "Bob" and "Nishmi" will be notified via email. If it was done accidentally by "Bob" he can undo that change.

• Action Tracking

Track every action with a log so that if anything goes wrong/ or if any illegal action performed by a malicious user, every step can be undo and reset for a specific date.

• Data Encryption

Data storing in the database will be encrypted or hashed based on the importance of the data.

The Budgeting mechanism

Budgeting mechanism will be a branched one from the ticketing system. It'll help admins to forecast the budget for the next FY. The planned system budgeting process can be described as below,

• Individual users will submit their next FY expenditure with parameters like Country, Region through a budgeting ticket.
• Those tickets will be taken into account by Budget wranglers of the region and categorize according to parameters. Then process the total.
• After the budget allocation submitted by sponsor each regions budget will be automatically adjusted according to the parameters set by budget owner and divide across the regions.
• Then there will be initial amount submissions to the accounts for upcoming FY.

Final Deliverables

• Basically there will be few core components those need to be in the High Priority state
  • Ticket creation for every users who has a FAS account.
  • FAS login enable and disable feature in the configuration level.
  • File uploading in to the tickets (Bill proofs)
  • Stage change log of each and every ticket.
  • Approval privilege can be applied in to Approval roles in the Regional basis and FAmSCo basis
  • As the initial setup the admin will be able to setup set of main accounts with their type and credit/debit rules.
  • On-site report generation and off-site report generation (API key auth) with customized queries.

• Mid priority
  • Email notification system for the ticket creator, approval and admin(s).
  • JQuery UI for the back-end and front-end.

• Low priority (If time permits)
  • Integrate GAvatar in to user profiles.
  • Formatted HTML output for API responses.
  • Budget projecting mechanism

The Timeline

Development Methodology

I'll be using the iterative fashion development. It allows me to manage my development stages, revisit the coding I've done earlier and refine/patch them if needed. Also from this development methodology, it'll allow me to contact my mentors at least once a week in the worst case scenario.

Phases of the Development methodology

• Design and Implementation (~ 1 week)
  • Prepare a check-list of TODOs
  • Identify,design the classes.
  • Define the reverent database fields
  • Identify and write test cases for the current iteration.
  • Communicate with the mentors and get the confirmation about the design.
  • Blog about the design and prepare the initial documentation.
  • Develop the Models, Controllers, and add Views.
  • Refine the code where necessary.

• Testing and Documentation (~ 1 week)
  • Discuss about the new codes and refinements with the mentor.
  • If there are more refinements to do, finish them up.
  • If test cases are available, do the tests and check whether they are passing.
  • Enhance the documentation by adding content.
  • Self evaluation about the iteration. Review the check-list. Prepare a list of components those can be improved in the next iteration.
  • Blog about the achievements of the iteration.

Details and Timespan of the iterations

Project Familiarizing Period

• Defining the use cases
• Reading the Documentation of CakePHP and test codes(perhaps come up with a good code for login?).
• Refine the idea about the system and clear up the problematic points.
• Learn additional things which will be useful in the project
  • AJAX helper component in CakePHP

Iteration #1 (June 16 - June 30)

I'll start with the core components and develop the additional components around them.

• Integrate login mechanism with FAS JSON auth interface. Hack CakePHP if there is requirement arise. Development of login mechanism with internal roles. Defining the boundaries those each role spreads.
• Develop accounting system in according to accounting concepts.
• Setup account type per-configuration interface for Admin.

Iteration #2 (July 1 - July 14)

• Develop the ticketing component.
• Integrate ticketing component with the core accounting system and define the states.
• Add the parallel currency recording feature to both ticketing and accounting components using Google Currency Converter API.

Iteration #3 (July 15 - July 29)

• Add additional styles to the interface to get a cool look.
• Add responsive components to the UI for ease of access to the users (AJAX search for relevant form fields)
• Prepare the system for the mid evaluation

Iteration #4 (July 31 - August 20)

• Defining Reporting filters and reporting output mechanisms.
• Develop simple RESTful API to access the reporting features.
• Extend the reporting API.

Iteration #5 (August 21 - September 2)

In this iteration I'll be bit busy with University project presentations and evaluations. By pre-considering that reason, I allocated a light work load to this iteration.

• Develop the front-end.
• Add the front-end control features to the back-end.

Iteration #6 (September 3 - September 16)

Final iteration almost all have been done in this stage.

• Test the functionality in the system as a whole.
• Write the .spec to the system for packaging.
  • Almost all dependencies for this project seems packaged already. So there will be no need of packaging the dependencies.
• Package the system.
• Test deployment of the packages.
• Finish up the coding and get ready for the final evaluation.

Potential Mentors

Buddhike Kurera and Charindu Thiwanka are my potential mentors.