- 1. Allow users to pass activities over to each other
- 2. Development of interfaces to handle more complex projects
- 3. Trust Funds “overview interface”
- 4. Co-financing “overview interface”
- 5. User management
The main goals of sprint 4 are:
- allow users to pass activities over to each other
- development of interfaces to handle more complicated projects
- Trust Funds simple interface
- Co-funding simple interface
- implement some user management (authentication / authorization)
- data in the live AIMS should not be touched
- data in the test AIMS can be changed and adjusted as necessary for the purposes of testing
- data in the IATI import tool can be deleted and re-generated at will throughout the development process, until we agree otherwise, perhaps in some of the last few sprints.
DP data overview
For the purposes of this sprint, we will use data from Canada, DFID, UNDP and World Bank.
|Organisation identifier *||CA-3||GB-1||XM-DAC-41114||44000|
* this is currently the only- or most-used identifier. There may eventually be more than one identifier in use; see below.
The data from all four DPs is good. We’re looking at UNDP and World Bank data in this sprint because they operate projects funded by Canada and DFID. Note that the World Bank does not yet publish Trust Funds in its IATI data.
1. Allow users to pass activities over to each other
In sprint 2 (step 3) we allow users to “Filter DP activities” - as a way of sorting activities into:
- activities that are the DP’s own projects
- activities that are the DP’s contributions to projects managed by other DPs
We now want to save the second set of activities and record them as having been passed across to the other DP. This could just be a question of altering the basic table we created in sprint 1 by adding an additional two columns:
|assigned_to_organisation_id||44001||This project has been assigned to another organisation (default value should probably be the original organisation’s organisation_id? Or perhaps
|assigned_to_datetime||2016-02-29 19:53:00||A timestamp for when the project was assigned to another organisation.|
We may want to think about a notification system within the app for alerting other users that these sorts of things have happened, though perhaps we can just use the assigned_to_datetime to alert the organisation receiving this activity when they log on.
2. Development of interfaces to handle more complex projects
There are two main types of complicated projects we need to handle:
- Trust Funds – where different organisations put money into a big pot (the pot is managed by a particular DP - normally the World Bank), and projects are then funded out of that pot;
- Co-funding – where different organisations agree to fund the same project, but disburse their money separately, directly to the implementing organisation.
The main way that we handle this is to create an interface for the organisation that gets assigned the activities (let’s call them the Managing DP). It then becomes that organisation’s responsibility to sort out how activities should be mapped together.
The Managing DP, when they log in, should be presented with a list of activities that have been assigned to them, with the option to map them against:
- one of their own projects, OR
- a trust fund.
In the drop-down lists in the mock-up below, all the Managing DP’s projects and all trust funds should be shown.
3. Trust Funds “overview interface”
Once the Managing DP has assigned activities to their own projects or to a Trust Fund, they should be able to decide how to handle this data.
In this interface, we assume that the user has the right to handle Trust Funds. In reality, we may only want to give these permissions to some DPs (e.g. the World Bank) – but we can come back to that later.
We should create a simple overview of the Trust Funds interface that allows the Managing DP to decide what to do with the commitments that have been assigned to them (and which they have then mapped against a Trust Fund). They can choose to allow these new commitments to be entered into the AIMS, or to reject them.
In the AIMS, the cumulative amount of commitments per DP is stored rather than any breakdown over time. In IATI data, we can show individual commitments.
We don’t need to enter this data to the AIMS at this point – just to create the interface that makes it possible.
4. Co-financing “overview interface”
Once the Managing DP has assigned activities to their own projects, they should be able to decide how to handle this data. We assume that where projects have been mapped together by the Managing DP, they are co-financing arrangements.
We should show the list of the Managing DP’s projects where other organisations’ projects have been mapped to them. We should show:
each disbursement and commitment for the project by organisation (according to the AIMS data)
each disbursement and commitment for the project from the new IATI activities that have been assigned from other DPs
The user should be able to decide whether to accept or reject financial data from other DPs.
They should not be able to reject individual transactions, but they should be able to remove all disbursements and/or all commitments from individual DPs. We should show the breakdown of transactions for now. If it’s too much data to show on the page (or if it isn’t clear) then we can show the total value of commitments or disbursements.
5. User management
As part of all of this, we will need to introduce the notion of a “user” to the interface. This will be the mechanism by which we will allow users to be responsible for their own projects and to pass responsibility over to other user.
If possible, it would be good to make use of the user management in the AIMS, but this should be a loose coupling so that the IATI import module remains somewhat generalised and could be applied in other systems that do not use exactly the same AIMS.
We should then create a simple welcome screen for a user which allows them to import their organisation’s projects - taking us to the very first tab of sprint 2.