houdiniproject / houdini Goto Github PK
View Code? Open in Web Editor NEWFree and open source fundraising infrastructure for nonprofits and NGOs
Home Page: https://houdiniproject.org
License: Other
Free and open source fundraising infrastructure for nonprofits and NGOs
Home Page: https://houdiniproject.org
License: Other
Occasionally, a Stripe Connect account will require an elevated validation process. Stripe requires this when there's a mistake in the DOB or the last four digits of the SSN for the person setting up the nonprofit account. Houdini has support for turning on an "escalated" verification mode which allows the nonprofit user to enter their full SSN for verification. This requires setting Nonprofit.verification_status
to escalated
. While we do update the verification status through a cron job (and it could be done through a web hook), we don't currently have an automated way to set the verification status to escalated. For CommitChange, I manually set the escalation status via the rails console when we find out it's necessary. This is not ideal :)
Adding support for updating to escalation status requires the following features:
Nonprofit.verification_status
to escalated
We need to add a link for terms and conditions to all pages.
This is needed due to the AGPL's requirement that a source download be available. It must have the following features:
Ideally, it should have the following features:
I've noticed that the timestamp used as part of the filename for migrations are not correct. The problem is that an additional digit was accidentally added into the name. This leads to conflicts on merges because rails simply adds one to the end last digit in the timestamp portion of the migration filename.
A few things should happen:
Puma and Rails both supports multithreading. That said, it's not set up in the current code. Additionally, it's not entirely clear that Houdini's code is actually threadsafe. Setting up multithreading may require the following tasks:
This would be best handled by someone with experience dealing with Rails and multithreading
Currently the build process in README.md is a bit cumbersome. A number of the steps could be scripted. A simple bash script, particularly for adding settings and environment variables, would be much appreciated!
Expectation:
Every supporter who buys a ticket with cash or check and is then added into the system receives a receipt that mirrors the online ticket payments.
Reality:
Receipting for event tickets logged as offsite payments do not include payment information, just general ticket information.
Resolution:
Add payment information to all event ticketing. (Most offsite donations don't include receipting, but in this case, attendees have a higher probability of wanting emailed "tickets" sent to them for their records; adding payment information standardizes receipting.)
It seems there is an option to automatically push/PR from one to the other, I need to check and install
Expectations:
The import system should be able to handle formatting differences in file uploads.
Reality: A CommitChange user tried to import a file that had a space in the name. The system said the import was complete, but no files were added. Deleting the space in the file name corrected this issue.
Resolution 1: Improve error reporting to recognize this issue.
Resolution 2: Change the import system so that a space in a file name doesn't create this error.
--
Does this still happen with the move to ActiveStorage? We should check!
If you add an attendee to your event manually, via the "+ Attendee" button and select them as paying via cash or check, one would expect the total payment amount in the attendee record to be correct. Unfortunately, currently, the amount displayed is $0. I can assume the calculation calculates using only credit card transactions. This needs to be changed.
Currently, Houdini uses Ruby 2.3 and the latest version of Rails 3.2. Ruby 2.3 is in security maintenance mode and will stop receiving security updates near the end of March, 2019. Accordingly we need to upgrade to Ruby 2.4 or higher. Additionally, as Rails 3.2 is not supported on Ruby 2.4 or higher, we need to update to at least Rails 4.2.
If you add an attendee to your event manually, via the "+ Attendee" button and select them as paying via cash or check, one would expect their payment to be listed in the payments view as a Ticket Purchase. Unfortunately, right now they list as an offline donation.
NOTE: it may be relevant to look at #36 when tackling this issue.
Expectations: Organizations signing up for accounts on Houdini-generated platforms outside of the US should be able to add accurate location information for their account.
The reality: When an organization creates an account, the fields that collect address information do not support addresses outside of the US.
Resolution: Create a modal that includes fields for international address information while balancing support for nonWestern address conventions and the need for security/fraud prevention.
Expectations: Have a clear display that tells users on the Payouts page or in the export itself that Payout Reports times are UTC to avoid confusion.
Reality: Some users have issues with reporting needed for tax purposes and acknowledgements, especially at the end of the year, because the time stamp isn't there.
Houdini Project's front end will be rewritten in React. The rewrite in React will have the following characteristics:
Long term project.
Nonprofits expect donations, not supporters to be anonymous, and they need donations to show up in reports and displays as anonymous so that they can handle acknowledgements properly.
So far, my thoughts are:
1: Supporters should no longer be anonymous in the Supporters list, but donations should be anonymous when applicable in the display. So, it should say something like "Made a $1 anonymous donation" in the supporter entry
2. Donations should be clearly marked as anonymous in the Payments list at a glance (with icon or clear labeling)
3. Receipts should show clear labeling that a donation was anonymous for both the donor and the supporter
4. Activity feeds on profiles, campaigns, and events should show the donor as anonymous when applicable
User story:
Brave Trails, a nonprofit using CommitChange, finds that they have increased user error because they must use a donate button on their website or their profile page to process online donations that are called in or that have been mailed in. (This is a common scenario for many nonprofits who send out mailers.) They would like to have donate buttons that link specifically to supporters in the supporter record.
Ex. Jane Doe wants to donate $20. Jane Doe is already in the Supporter Database. To process the donation, the nonprofit would like to be able to go to Jane Doe's supporter record and add a donation through a button on her record, much like the + Donation button that already exists.
Expectation: When a user clicks on a list to sync with Mailchimp, it shouldn't be duplicated in the system, new users should be added to the existing list
User Story: a CommitChange nonprofit user thought lists had to be synced by clicking on the sync button for the selected tags and was creating duplicate lists over and over again.
Resolution: Ensure that once a list is synced, it is not duplicated in the user's Mailchimp account even if a nonprofit selects that tag and submits it for another sync.
Currently the unit tests succeed on Eric's computer but it doesn't work in the initially cloned state. Fixing unit tests requires figuring out what is missing in the default test config and adding it.
It's possible that the test config should be static code necessary for the tests to start and then each test would be able to modify Settings as part of the test. Who knows?
User Expectations:
Users want the ability to edit tags without having to delete them.
The current reality:
In order to change a tag, you have to delete it and add a new tag.
This specifically affects the Mailchimp lists. As accounts work with lists in Mailchimp, it can mess up their communications workflow to have to delete a tag that has a number of people attached to it.
One issue with React pages is that they're kind of big. Especially for people on slow connections they'll have some empty views while it's loading. We do have one already for other pages but it'll need to be modified for use on pages with React. I think for now we'll go with that particular code but I'm not sure it's exactly what we want long term.
The current homepage has basically no purpose. I propose we have the landing page simply redirect based on the following:
There are two rspec tests which fail when run as part of the spec suite rake spec
Add more detail :)
In some cases, a organization may never want to make onboarding possible. This is particularly the case for instances where there's a single nonprofit with no others. To this end, we need a setting that allows instances to not have to onboarding available.
The entire front end must be made fully accessible. As part of this, best practices for React should be used. The libraries to use are:
Associated with #5
As a policy, CommitChange supports all IE versions 9 and higher. This has been manageable to date but isn't without difficulties. That said, this policy may not be what Houdini wants.
Google is modifying their Maps API policy to prevent usage without an API key. Currently, there isn't a way to add an API key for maps used as part of Houdini.
Nonprofit User Story
Brave Trails, a CommitChange nonprofit, tries to retain email addresses for all supporters, even those who donate through check or cash. If they want to send an email receipt for donations, they have to copy the information from their payment records then either paste the information in their email client and copy the email address separately and paste into the email client to send the email, or if they're using Gmail, navigate to the Supporters dashboard, find the supporter, and send an email through the supporter entry. Both processes are time consuming and don't scale well with high volume.
Currently, we have a set of migrations listed in the db. This is normally alright but becomes a huge hassle with merging a set of migrations from multiple sources. For example, if your fork is relatively far apart from master, your migrations can be quite different and ordering isn't consistent or even work correctly.
Part of the issue is that Rails migrations are a bit naive and part of it is that we need to split parts of the application up into separate parts. For example, could moving parts of the app into different Rails engines simplify this process? I'm not sure but anything we can do to simplify merging db migrations would be greatly appreciated.
In the repo, a few files are saved in public
. Since this folder should be all generated info, this is a problem. These files should be moved into other folders as appropriate and then copied in via Webpack.
Additionally, after the files are moved, the public
directory should be fully gitignore'd.
Expectations: Donations made towards events will show up as under those events on all reporting.
Reality:
Donations made to an event (but not tickets for that event) aren't listed as associated with those events on the payout report.
Expectations: When a user makes a refund, they expect appropriate ID numbers to display on the refund record.
User Story: When San Mateo PAL (a CommitChange nonprofit) had to refund some duplicate charges, it was confusing as to which refund they had already made.
Resolution 1: Add Donation IDs to the refund display.
Eventually, almost all data retrieval communication should happen via an API. This API should be written as follows:
npm run watch
and npm run build
commands.Additionally, the API must integrate with Rails CSRF for website usage and OAuth for remote application usage (The OAuth support can be done in a separate step)
This is a long term project and will be discussed further on our Zulip and in other meetings.
Via Eric: Currently, you can only have a single address for a supporter. This causes problems for shipping addresses replacing the default address, as well as other cases where the address is different. The multi address support needs the following characteristics:
There are two ways to handle this going forward:
The first way is more correct and more reliable long term while the second is probably quicker to implement.
Expectations:
Users expect to be able to sort the display for Campaign dashboards by different data points to have a better view of data at a glance.
Reality:
Currently, you cannot sort campaign dashboard displays by the data present. For example, some of our users want to be able to sort by campaign gift levels, so they can see the info on their screen at a glance without having to make an export.
Expectation:
When a user creates an export from Supporters, a field with tag information will be included in the export.
Reality: When a user creates an export from Supporters, that information is not included unless a custom report is created by a dev.
Resolution 1: Create the option to add tags to a Supporter export (like a checkbox that comes up near the Export button)
Resolution 2: Add tags to all Supporter exports.
If a recurring donation card fails to charge three times, we mark it as failed so it won't be charged again. The only way via UI to reset the failure status (set n_failures back to 0) is for the donor to go to their donation management link and enter their card info again.
This is a logical requirement if the cause of the donation failures is card expiration. Cards can also fail though due to insufficient funds in the account. In that case, when the problem is corrected, it makes no sense for the donor to have to reenter credit card info.
While unclear as to how to fix this, the problem could be solved by providing a mechanism for the nonprofit to turn a recurring donation back on. Or there may be other ways?
The issue: Nonprofits can add discount codes to their events, but they cannot attribute those discounts to specific ticket levels. For example, a nonprofit may want to exclude VIP or sponsorship levels or only allow the discount for specific levels. They may also want to put a number cap for how many discounted tickets someone can buy (for example, they may want to limit the discount to two tickets).
Solution 1: Make it so that users can attribute or exclude discounts to specific ticket levels.
Solution 2: Allow users to place a cap on how many discounted tickets supporters can buy.
User story: "An organisation needs to be able to setup and manage events that are based outside of the United States, but Houdini's existing address fields do not allow for locations without US States. To solve their problem we need a solution that standardizes address collection without losing well-structured data."
Overview: Addresses throughout Houdini should be assessed and restructured to accomodate as many international use cases as possible. The most pressing features for internationalisation relate to events.
During the licensing, the .es6 files were neglected to be included. Those files should be under LGPL3 or later.
Users have requested:
and
For privacy reason, we want to limit as much as possible using external websites that might track our users. One of the ones I'd like to remove is polyfill.
I don't know enough about what "advanced" features we use to know if we still need polyfill, but at least move to that version
<script>(function(d,s){
if(window.Promise&&[].includes&&Object.assign&&window.Map)return;
var sc=d.getElementsByTagName(s)[0],js=d.createElement(s);
js.src='https://cdn.polyfill.io/v2/polyfill.min.js';
sc.parentNode.insertBefore(js, sc);
}(document,'script'))</script>
This only includes polyfill.io when necessary, skipping it for modern browsers for faster load times.
We want to have Travis CI working so we can do continuous integration of pull requests. This only really makes sense if #52 is completed :)
Expectations: You should always be able to modify customizations to pages that you've set.
Reality: If you go to an Event and add a header image, you'll see an option in the event settings to hide the header text.
If you delete that image, the option to hide the header text (a checkbox) will disappear. However, if you have deigned to hide the header text, the option to show the header text will be gone, so you won't be able to add the header text back unless you upload another photo and go into the settings before you delete the photo.
On the onboard page, it makes no sense to have an in-depth header and footer. In fact, it should be very minimal so the user can focus solely on the task at hand. I'm unsure whether this feature will have use cases outside of the onboard page but who knows?
Currently, only the donate form is translated. Eventually, the entire app should be translated.
Our settings system is pretty great but using .env and our test settings is a bit brittle. Ideally, the settings could be entirely defined in spec code. This allows us to more easily test different scenarios with different settings.
During the release process, it's possible some CommitChange content, either logos, wording or urls, were missed. These need to be removed and, where appropriate, possible to set via Settings.
Settings are in config/settings.yml
.
Expectations:
When a user looks at a supporter records, it should include all donations and refunds to avoid confusion. Instead, this supporter is only showing donations and not related refunds.
Resolution 1: Create a display where refunds show in the Supporters display
Resolution 2: fix whatever display issue is keeping refunds from showing in Supporters display
Currently, there's no real organization registration page to speak of. Some users, like CommitChange will need this.
The registration page will have the following features:
It should have the following features:
Generated code when using rails generate
should have the proper license headers on top. As of now, they do not.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.