Why:
When there is not Budget accepting (Investment creation) the guide page
doesn't have much sense as it will give the user an option that can't be
used (creating an Investment).
How:
Using `Budget.current&.accepting?` conditional at GuidesHelper to link
to new proposal link instead of guide page, and adding an scenario to
guides feature spec for it.
Why:
Its a really huge script, and conflicts are hard to resolve on forks,
with indivudal scripts its easier to make custom changes.
How:
Following @mariacheca example using require_relative and a file under
the db/dev_seeds/ folder
Why:
Newsletters without a valid user segment can't be sent since there is no
recipient user email list.
How:
* Hiding the send button at the form
* Preventing an invalid newsletter from being delivered at the controller
Why:
A Newsletter can only be sent if the are available user recipient emails
and that means the `segment_recipient` value actually corresponds to a
function on the UserSegments class.
We could rely on the UserSegments::SEGMENTS constant as the list of
possible user segments functions that a Newsletter can use to gather
emails, so any value not included in that hash would not be valid.
But to be 100% sure the newsletter can get a recipients_list we should
just check if the UserSegments class has a method with same name as the
`segment_recipient` value.
How:
* Adding an validation method that checks if UserSegment has a method
with same name as the `segment_recipient` value.
* Adding an scenario to the Newsletter model spec to check this
Why:
Newsletter attribute `segment_recipient` is an integer to be used as
enum. There's no advantage to store a number instead of an string if the
ammount of elements in the table is not going to be huge, or we can take
advantage of using an enum.
Also maintaining both Newsletters enum paired with UserSegments::SEGMENTS
would be a maintenance burden.
How:
* Migration to change segment_recipient column from integer to string
* Removing enumeration from Newsletter model class
* Using UserSegments::SEGMENTS instead of Newsletter.segment_recipients
or integer values
Why:
UserSegments are not only used for Newsletters or Email downloads, but
also for internal Global Notifications. We don't want to have that scope
hardcoded inside UserSegments as users that have opted-out from the
newsletter should still be recipients of global notifications.
How:
Removing the scope from the UserSegments `all_users` method that acts as
base for all the other segments. Including that `newsletter` scope only
on the places that is relevant:
* When listing recipients for a newsletter
* When downloading a listing emails that can be newsletter recipients
Also updated relevant tests
We have a custom implementation to avoid doble submissions which causes
some custom problems 😌
This commit should fix the following three specs
spec/features/comments/legislation_annotations_spec.rb:367
spec/features/comments/legislation_questions_spec.rb:333
spec/features/custom/probe_option_comments_spec.rb:298
One of the custom problems comes from ajax:success[1] not being
triggered, instead only ajax:complete seems to be triggered
We should remove this custom implementation and use the standard
solution provided in rails[2]
[1]
https://github.com/AyuntamientoMadrid/consul/blob/master/app/assets/java
scripts/prevent_double_submission.js.coffee#L28
[2]
https://stackoverflow.com/questions/9570912/how-to-disable-a-form-submit
-button-a-l%C3%A0-ruby-on-rails-way/9572893#9572893
