Dockerhub allows users to automatically build images from Github repos that contain a Dockerfile. We should set this up for the action center.

Affiliation sets represent:

• a list of institutions (ex. U.S. colleges and universities that take government funding)
• a list of of possible relationships (ex. student, alum, faculty, community member)

Administrators maintain affiliation sets. They should be able to upload a CSV of institutions. Not sure what the best way to let them input relationships is.

Some javascripts are required more than once, possibly for hoisting necessities?

//= require application/sticky_tools
...
//= require_tree ./application
...
//= require application/smarty_streets

TODO:

• Ensure all the javascripts are cucumber tested
• Clean up application.js so the requires are in a logical order and have no duplications (and confirm nothings broken due to the new hoisting arrangement)
• Document the heads of each of the scripts
• Modernize the js to be hoisted in the head, but engaged in the body

There's some weird stuff preventing turbolinks from being dropped in... like custom manifests...
https://github.com/EFForg/action-center-platform/blob/master/app/controllers/application_controller.rb#L34-L36
https://github.com/EFForg/action-center-platform/blob/master/app/controllers/welcome_controller.rb#L2

On FF, Linux Mint
  For call campaigns
    On my screen it looks like it reads "Email vour representatives"

https://act.eff.org/action/tell-congress-to-vote-no-on-the-tpp

The height can be changed to fix this, I wonder how the other browsers/OSes render...

Currently it's possible to export signatures from a petition-type action as a CSV that includes first_name, last_name, email, zipcode, country_code, and created_at. That's not super useful for actually delivering petitions. There should probably be an export tool that creates a file (can still be a CSV) with the full name, the city name, the state abbreviation, and the full country name. It would be nice, too, if that had a semantically meaningful name like $action_name-signature-export-YYYY-MM-DD.csv or something.

The admin/action_pages is pretty messy... listing lots of the old material we don't even think about anymore.

It would make things easier to have a filter dropdown box with options of "current", "archived/ victorious", and "all" so admins can easily see what's current, and set them to be featured.

For example, after 5 failed login attempts, block login to the username for one hour.

This would help mitigate brute force logins for a single account over the course of several months.

• act.s.eff.org (fastly)
  ** isn't serving assets with a cache header
  ** It seems to merely be proxying, not caching
• act.eff.org (fastly)
  ** rails-fastly isn't being used
  ** For logged in: The home page has a cache-control: max-age=0, disabling caching
  *** There are three representations of '', normal, logged in, and admin logged in
  ** Pull out as much configuration from fastly and put it into the app's header writes
  ** Investigate half implemented fastly stuff in app...

act.s.eff.org

This thing was behaving funny, as though fastly wasn't cache and was simply proxying everything. That sucked, but I think it's been fixed or being worked on by fastly now.

fastly gem breadcrums

Hmmmm.... check out the bredcrums surrounding prior attempts at using the fastly gem. looks like some crumbs left behind? https://github.com/EFForg/actioncenter-dontuseforissues/commit/4381bba28f372fb39441d7852ffb5a1e489cdca1#diff-8b7db4d5cc4b8f6dc8feb7030baa2478

After you try to register for an account, the site redirects you to the homepage. This must be a regression that's happened relatively recently, as it definitely wasn't the case before.

The "confirm my account" message is sent to the user, but they should be notified to look for an email in their inbox and that isn't happening.

When we push out emails or notifications to members, we would like to have the option of using a URL that encourages login/signup (with a button to continue on to the action without logging in). After login/signup, the user would redirect to the action...

More Visible at: https://github.com/EFForg/actioncenter-dontuseforissues/issues/411

Without doing much investigation, I just hit the below error while running a cucumber test in a private branch:

ActionView::Template::Error: uninitialized constant CiviCRM::SUPPORTERS_API_KEY
from /home/kentos/dev/work/web/action-center-platform/lib/civicrm.rb:91:in `base_params'

application.yml doesn't define a CiviCRM in my test env.

For instance, with regards to the TPP issues, we have the following action pages:

• Stop the TPP's Copyright Trap in Malaysia
• Stop the TPP's Copyright Trap in Canada
• Stop the TPP's Copyright Trap in New Zealand

There should be a spot, perhaps on the right sidebar, which indicates to users that there are multiple actions related to this issue, and they might want to navigate there in order to take action.

The last_name of set|set&set made the word 'set' seem to fall under the email column. lulz!!!

For petitions, we'd simply check if anyone with that email has signed before. If so, ignore the signature and don't attempt to deliver an email. This will reduce the risk of spam.

See changelog for details

As it stands, there are two types of users, admins and non-admins. Below is ideal:

Roles:

• Activist
  • admin as it is now
  • edit ActionPages
• Administrator
  • grant roles to other users
• Partner
  • download CSVs
  • define newsletter privacy policies
• Collaborator
  • View draft campaigns
  • View analytics
  • Remove dummy signatures from petitions

I don't want to forget this as I'm playing around with optomization code:

sudo apt-get install libqt4-dev libqtwebkit-dev

these are deps of the new travis-ci capybara-webkit additions.

Alternatively, I could set up the post-recieve hook to skip installation of development/ test gems, which I thought it was already doing actually.......... That's a best practice so testing never interferese with the production state....

I'm encountering the dreaded:

SystemStackError in *
stack level too deep
actionpack (4.1.10) lib/action_dispatch/middleware/reloader.rb:79

I'm still trying to figure out what gives. Been commenting away gems to no avail on my local. I'm getting close though, the specific crash is taking place in /dev/work/web/action-center-platform/app/views/welcome/_meta_tags.html.erb when trying to view the index page.

On line 16:

[4] pry(#<#<Class:0x007f162c3f3bc8>>)> twitter_handle
SystemStackError: stack level too deep
from /ruby-2.1.2@action-center/gems/pry-0.10.1/lib/pry/pry_instance.rb:355

Can we make it so when a user reaching say the TPP Canada page, in some way links to related ActionPages, such as TPP Malasia, or TPP Japan are shown to them in case they live there?

At least in Thunderbird, the escaping puts + signs between each word instead of the expected spaces. I think it's defined in the action page helper, but I don't know enough about the escaping there to know what's wrong.

Other than the two javascript/ css cherry picks, the last stable commit pushed to production was...

57e7286 Building in support for new recaptcha-style forms

I'm going to push all these commits to the staging server, diagnose them carefully, listing any problems in this thread, and then upon resolution, will push them to the production server.

Commands to undo the commit incase it's fubar:

#  On production SSH
$  rake db:rollback STEP=1

# On dev git repo...
$  git push production 9e9c784:master

That should put things right in less than a minute or so of downtime.

Currently, both share the settings defined in the ac_embed javascript variable. It would be great to either allow separate settings passed to the embed script or put a distinct body class on the embedded iframe for more targeted styling.

(See https://savecrypto.org/ for an example of two embeds on one page.)

This would work around a bug in CiviCRM where a contact import fails if the postal code is longer than 12 characters.

This could be done by letting staff embed the "all signatures" view partial within the content field (similar to the letter style).

Actions in non-english language show up with bits of English thrown in there. That's really jarring.

In particular:

https://act.eff.org/action/o-brasil-construiu-uma-das-melhores-leis-para-internet-do-mundo-impeca-o-congresso-de-aprovar-a-pior

• Individuals
• Display another 3
• The actual EFF Action logo image
• All the navigation links
• All those 'bottom of page' links

UPDATE:

There's a config/locals folder, not being fully leveraged... hmmmmm..... search t(:speak_out) to get the gist.

Petitions are storing invalid email addresses such as foobar@gmail

Running rake db:migrate on a fresh database will not generate the same schema that is tracked into this git repo.

Arguments Towards Issue Resolution

As briefly discussed in person, my thoughts on this issue are that:

• It is unconventional to have a schema.rb that cannot be auto-generated via the rails migration feature
• It gives me a general feeling that things are buggy/ sloppy
• External (and possibly some internal) devs will have a slightly dis-similar database schema than our production server

I did a quick speed test and running rake db:schema:load takes 4 seconds, whereas rake db:migrate takes 5. Given that this is a 1-time command in the development cycle, I perceive the performance difference to be negligible.

Precautions with Resolving this Issue

As you pointed out in person, I will make a point to:

• Not make changes to the production database
• Not hack that cool hidden rails table until I can find legitimate supporting documentation on doing so

Difference between gh schema.rb and migration generated schema.rb

The difference between the gh schema.rb and the migration generated schema is very small. Basically the gh version contains extra stuff that is not used or accessible to the rails app. For the most part, these extra tables and fields exist because the migration files were created and run, and then deleted, but the schema.rb file was not reverted via rake db:rollback. In a special case... the uuid thing... we ran a migration to enable ossd on the database, but didn't backdate the timestamp on it, which prevented us from using the feature properly.

What's different in the gh schema.rb:

• An unused table, 'action_page_images' exists, it's migration was eliminated because an alternate implementation was used instead
• An unused table, locales exists, I can't even find it's migration in the old git repo
• The action_pages table contains an un-used action_image column with missing migration
• The action_pages table contains an un-used call_tool boolean, with missing migration (we used call_campaign_id instead, btw)
• The ID column for ahoy_events is defaulted to uuid_generate_v4() which we didn't set during the enable_ossd episode because we needed to backdate the enable_ossd migration to before the creation of the ahoy_events table (such that uuid_generate_v4 would work)
• The ID column for visits is defaulted to uuid_generate_v4....

Check out Rainey's user/show page...

It states: "you are in the 99th percentile"
action you've taken: x calls, y petitions, z emails. Total: 34"

where x+y+z != 34... not even remotely...

The mobile app needs an Access-Control-Allow-Origin: * header on https://act.eff.org/action.atom

I'm not sure off the top of my head the correct way to add such headers to end points. maybe faster for @TheNotary to patch this in?

We want to make a set of options for location data available to users who are creating an action. This will default to international, allowing users to select country, then state or province.

See: ankane/chartkick#127 (comment)

Our Gemfile still specifies my fork: https://github.com/EFForg/action-center-platform/blob/master/Gemfile#L61

We should change this to use the upstream Chartkick, as well as refactoring to ensure we are compatible with any API calls that might have changed.

In the README it says:

"By default, the test and development environments are configured to use sqlite3"

This is not the case. The default adapter set in database.yml is pg, and the sqlite3 gem is not included in the Gemfile.

Tweets always begin with .@TARGET_NAME when it might be ideal to work the target name into the middle of the tweet text, such as This totally sux @TARGET_NAME, wtf?

https://github.com/EFForg/action-center-platform/blob/master/app/helpers/action_page_helper.rb#L22-L27

The plot thickens:

https://github.com/EFForg/action-center-platform/blob/master/app/assets/javascripts/application/templates/tweet_individual.jst.ejs#L5

Should removing teh forcing of a .@target as a prefix to the message, and instead make that what starts out in the body of the message when the user is creating a tweet campaign?

I'll need to write a migration to add in the tweet targets to existing tweets so I don't break existing tweet campaigns too (so no easy hotfixing).

These tests will work after the rspec tests after typing rake. Alternatively the tests will be envoked with cucumber. Firefox will be required. Key features such as loggin in as an admin and creating action_pages will be tested.

From Rainey: "If you sign a petition, you should NOT be having a pre-checked box."

The default state for subscriptions through the email tool should still be 'checked'.

When "show all signatures on the action page" is checked:

• signatures should appears in the main column below the petition
• signatures should be paginated
• the "recent signatures" teaser in the right column should not be visible

The email actions used to show an email signup prompt like this:

However they no longer display.

It would be nice to run a memory profiler on various requests, to make sure there aren't any long-running blocking calls:

https://github.com/tmm1/perftools.rb

If someone types in a non-US zip code on a tweet congress page, they get an endless progress bar instead of some kind of helpful error message.

Some petition signatures - presumably those submitted by bots - have invalid country codes

We're using a gem 'has_heartbeat' that enables an endbpoint, '/heartbeat' that checks the database connection and uptime of our system.

Is there something logging stats on act.eff.org somewhere?

Maybe this should be removed all-together, airbreak is a dependency of this gem which may being leaking log information that we wouldn't want it to (and has the potential to throw stack-level too deep which either masks the actual root of a critical error, or causes one).

The staging server setup is sub-optimal. Act.eff is important and deserves a crazy-go-nuts staging server with all the bells and whistles, such as:

• A script to automate a fresh copy of the RDS database be made
• A script that automates an in-sync S3 bucket be cloned

https://act.eff.org/admin/partners/5

There links to the pages on https://act.eff.org/admin/partners btw.

Looks like this does nothing, it was started, and then we went a different way with things? There's a migration and a model. Easy commit unless I'm mistaken.

title, summary, and description. If an AP is made without these, index view gets crashy.

Affiliations represent an (institution, relationship) pair - for example (UC Berkeley, student).

Each affiliation is associated with a signature.

Users create affiliations when they sign the petition (if affiliations are enabled).

Does anyone know what's up with this button? It seems like it would bring you to the unpublished action_page, but it does nothing...