Platform
Updates / Bug Fixes
- We've released updated informal German translations (de_AT). A very big thank you to Johanna at #Aufstehn for updating the translations to be gender neutral.
- As part of our response to a recent outage, we’ve added protections to the codebase that automatically analyze database migrations for risky patterns before they are run. This will reduce the risk of database changes that cause customer facing platform instability or downtime.
- We were seeing issues when syncing new signatures to ActionKit if people signed using special characters (e.g. 𝖙𝖍𝖎𝖘). Now, we'll convert those characters before attempting to sync to ActionKit.
- We fixed an error that was preventing admins from viewing details about a blast email if the locale that the blast email was written in had since been removed from the platform. This could happen when a customer removed a language that was previously used on the platform.
- We no longer support embedding nearby petitions in external sites. (This embed code was previously tied to, for example, https://demo.controlshiftlabs.com/petitions/near/new).
- We've updated the way we pull customer-provided translations into the platform. Now, when translations are completed, the updated files will be automatically pulled from Transifex. This should decrease the time it takes for us to deploy translations, by notifying us when translations are completed in Transifex.
- We've improved the server side performance of a variety of pages in order to more efficiently serve requests.
- We've introduced a new liquid text filter,
sanitize_for_email
which can be used by customers to sanitize user strings that are included in emails more comprehensively than traditional HTML escaping. This can be used when customers are worried about email clients auto-linking text strings that contain URLs. Using thesanitize_for_email
liquid filter prevents auto-linking, in addition to more traditional sanitization, to prevent XSS vulnerabilities from user input strings. - We've published an open-source ruby gem for ActionNetwork’s API. This will be used to power a forthcoming integration with ActionNetwork.
-
Petitions
Updates / Bug Fixes
- For organizations with regional teams, we've updated the way we handle petitions created without a specific location. Previously petitions designated as 'national or global campaigns without a specific location' were not automatically given a region upon creation (meaning that they would normally not be included in pre-filtered regional admin views). Now, when an admin of a regional team creates a location-less petition, the petition will be automatically assigned to that admin's region.
- We've fixed an issue where petition signature forms embedded on other sites weren't working correctly when signers were using Safari (on mobile or desktop). Changes to Safari's default configuration prevented us from setting the signature cookie within the embedded iframe, which stopped the signature from being added to the petition. We've updated the way we handle cookies for embedded petitions and signatures from embedded forms are working again.
- We've updated the way we handle petition flags, which are created when a site visitor clicks to flag a petition as inappropriate. We're now creating a member record when a petition flag is created so that the flag is associated with any other actions the user has taken on the site. When a user's information is deleted or anonymized, we'll also delete the information about the flags they've created. We're also automatically removing IP address information from flags that are older than 60 days.
- We updated a validation that was preventing admins from receiving test emails for petition event invitations. When the moderator requested the test email, we were not sending the test email if the admin had not signed the petition. Test emails now work as expected.
- We've updated the way we send notification emails to decision makers. We're now sending those emails from
no_reply@decision-makers.cslemails.com
and setting the organization's main contact email address as the email's reply to address. Changing the from email address, and updating the relevant SPF and DKIM records, will help improve the deliverability of these decision maker emails.
- We've fixed a bug where filtering the all petitions list by date and then clicking to export led to an error page instead of a CSV.
- We've released support for changing the text of the automatic petition emails based on a petition's status. We've implemented this using liquid, and the new parameters are:
suppressed?
,approved?
,good?
,unreviewed?
,prohibited?
. As an example, if you wanted to hide a block of text if a petition is moderated to suppressed, you could put{% unless petition.suppressed? %}
at the start of the block of text and{% endunless %}
at the end. Similarly, if a block of text should only show if the petition is moderated to approved, you could put{% if petition.approved? %
at the top and{% endif %}
at the end.
- We've added support for using
{{ petition.creator_display_name }}
in email templates. This variable uses the petition creator's name as displayed on the petition page, which may be different than the name in the petition creator's user account (if the display name has been overridden by admins in the petition's settings). - We've modernized and cleaned up parts of the front-end code which renders the petition signature form.
Events
Updates / Bug Fixes
- For organizations with regional teams, we've updated the way we handle virtual events. Previously virtual events were not given a region upon creation (meaning that they would normally not be included in pre-filtered regional admin views). Now, when an admin of a regional team creates a virtual event, the event will be automatically assigned to that admin's region.
- We've updated what happens when an event host is anonymized. Previously during the anonymization process, at the point when an event's host information was being switched from the user being anonymized to the account in charge of taking over orphaned assets, we were mistakenly sending the 'thanks for agreeing to host this event' email to the user being anonymized, not the org admin. The anonymization process would then continue and the user's information would be appropriately scrubbed. Now, we're sending the 'thanks for agreeing to this event' email to the appropriate user.
- We've fixed an issue where after RSVPing to an event on iOS, the facebook messenger icon in the RSVP form's share tools was abnormally large.
- Previously, when uploading a list of events that shared a common event title, some of the events would fail because they didn't have a unique slug. We're now dealing with duplicate names appropriately.
Nothing new in groups or VisitThem.
† This feature required new text strings. If you're using the platform in a language other than English, you may need to provide updated translations.
Comments
0 comments
Please sign in to leave a comment.