Skip to main content
If you are organizing essential services or emergency response to COVID-19, activate your free account


commented on Donations API
The recruiter_name_or_email field does not work as expected/documented…

Create Endpoint:
– When creating a donation, if the donor’s recruiter is not null then the recruiter will be credited as the fundraiser, otherwise the donor will be credited as the fundraiser. The fundraiser field is supposed to be writable via the recruiter_name_or_email field, but due to a known bug this does not work. []

Update Endpoint:
– When updating a donation, the fundraiser for that donation will be set to the donor’s recruiter. If the donor does not have a recruiter, then the donation will not have a fundraiser once the update is complete. This behavior is absolute and will overwrite any manual changes made in the control panel. If you rely on the fundraiser field, you should use the Donation Update endpoint with great care (or not at all).
posted 2020-01-13 09:24:50 -0800
commented on Exports via API do not include "updated_at" field
I’ve noticed that the “updated_at” field is now included in these exports.
However, all “*capital_amount_in_cents” fields are now gone from these exports.
posted 2017-03-14 09:15:17 -0700
tagged Mark Dunbar's Request Followups API with Important
posted 2015-11-07 12:37:36 -0800
commented on Is this a security problem? Change of details only needs email address
I just came across this issue when trying to setup a signup form for organizations. If a person already in our nation uses the same email address to signup their business their Person record is converted to an Organization record, the last name is overwritten with the business name, and everything else on the signup form is used to overwrite the existing record – even empty fields overwriting fields that previously had data.

Seems like this can cause data corruption, whether or not the intent is malicious.

I have emailed my point person about this and the main workaround that was suggested is to wrap all signup fields except for email and name with the conditional sorta_logged_in. That would allow/force users to “sorta” log in before updating any additional information on an existing record. This helps keep existing data from being overwritten – if only empty fields are shown on the signup form – but garbage data could still be entered in the empty fields.

The best solution, in my opinion, is what Ethan suggested, “if you enter an email already in the database, you are challenged to log in”.
But an alternate solution, I think, would be to implement the logic used in Imports – put a checkbox on the Signup Settings page that allows Control Panel users to choose whether or not a signup page will Overwrite existing data if it finds a match in the database.
posted 2015-05-29 07:27:06 -0700
commented on Unexpected top nav behavior on tablets in landscape
Jacqui – unfortunately, I was never able to fix this problem.
posted 2017-07-27 05:40:37 -0700
commented on Event RSVP Email Updates
Josh – I have a few different thought processes going regarding this checkbox, so forgive me if my thoughts are disjoint.

Global Email List – It seems that this, and other similar checkboxes throughout NationBuilder are used as an all-or-nothing flag giving (or taking away) the ability to contact somebody through email. There does not seem to be a concept of mailing lists natively built into NationBuilder. Is this correct?
Sure, we could maintain lists using tags, but then we would need to build in our own functionality of allowing people to subscribe to and unsubscribe from particular lists.

Event Specific Email Correspondence – It seemed to me (and your answer seems to suggest the same) that the email updates checkbox on the Event RSVP page would grant or deny us the ability to email people regarding the event they for which the were submitting the RSVP. However, there is no built in way to communicate with those that have RSVPed unless we choose to tag them.

Regarding good and bad policies – consider the person, a non-supporter, submitting and RSVP to attend an event and leaving the email updates checkbox checked because they would like to know if there are any updates regarding the event. Subsequently they begin receiving non-event related emails from our nation that they did not explicitly subscribe to – not knowingly, at least. Could that not be considered bad policy that might even result in a loss of trust between that potential supporter and our nation?

Final thoughts – it seems as though there is no workaround to this issue other than the one you suggested, except I contend that the text you suggested is misleading.
For new supporters the text would have to be worded such that they knew that checking the box meant we might send them emails unrelated to the event, but unchecking the box meant they would not get an email update if there were any event changes.
For existing supporters the text would have to be worded such that they knew that checking the box would not have the effect of them receiving duplicate emails from us, and that unchecking the box would unsubscribe them from all mailings.

Since the text next to that checkbox seems like it might be quite wordy, is there any way in NationBuilder to send an email to people when they unsubscribe – a final farewell, if you will, and perhaps an easy way back in for those that have unsubscribed unintentionally.
posted 2014-03-06 13:50:21 -0800
commented on Get tags of an event in a loop
This should get it for you:
{% for event in page.calendar.events_upcoming %}
   {% if event.tags_count > 0 %}
      var event_tags = new Array();
      {% for eventtag in event.tags %}
         event_tags.push('{{ }}');
      {% endfor %}
   {% endif %}
{% endfor %}
posted 2015-02-27 19:49:24 -0800