* Add a mascot_user_id to SiteConfig
Also allow it to be updated from /internal/config pages.
Co-authored-by: Vaidehi Joshi <vaidehi.sj@gmail.com>
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
* Add spec for updating mascot_user_id
Co-authored-by: Julianna Tetreault <32834804+juliannatetreault@users.noreply.github.com>
Just a quick fix to filter banned users out of the vomit reaction lists,
we are doing essentially the same thing for unpublished articles. It
might worth handling this at the controller level if we experience any
performance issues.
* Custom social preview template for tags
* Added index on tags social_preview_template + small refactoring
* Add checks if index exists to tags migration
* Use active in place of sent on internal broadcast routes
* Add and use active scope on broadcasts
* Update seeds + specs to use active broadcasts
* Add note about active broadcasts to /internal/broadcasts page
* Changed sidebar campaign view
* feat: update the hml of the campaign sidebar config (do not show broken image if the link has not been set)
* feat: update the html and css to make it look like Figma
* chore: revert the classname change as we use write elsewhere
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
Because confirming a User vomit is a particularly destructive task, we
want to make it a bit more intentional. Ben recommended adding a confirm
dialog for these reports.
This commit also satisfies erblint's complaints regarding the select
element in the ransack search form.
* feat: port over changes (+ suggestions) from https://github.com/thepracticaldev/dev.to/pull/5892/files
* chore: add query over multiple lines
* refactor: move the sql logic into the controller instead of in the template
* chore: appease code climate
* Add "Welcome" type to Broadcasts, allow dynamic "authoring" of Broadcasts
This adds a new `type_of` to the Broadcast model: "Welcome". As we begin to create a new "welcome notification" workflow, we'll categorize them by making them all of the same type.
This also adds a concept of a "welcoming user", which can be set via an ENV var. The WELCOMING_USER_ID will allow us to explicitly set (and change) which user in the database is the one that "sends" welcoming notification. In production, we plan for this to be dev.to/sloan.
* Allow WelcomeNotificationWorker to accept + send any kind of broadcast
This abstracts out the logic of deciding which broadcast to send from the woker into the calling method. This will help us send many different kinds of welcome notifications using one, resuable worker class.
* Raise if a Notification can't be created
* Add STAFF_USER_ID as an ENV var
This is in preparation for moving away from SiteConfig.staff_user_id, and replacing it with an ENV var. We will need to set this in production first, and then make a separate PR to replace all instances of staff_user_id with the newly-set ENV var.
Allowing ids to be mutated by admins from the /internal/config pages is dangerous.
This could cause issues if an admin tries to update the SiteConfig.staff_user_id to an id that is another user's id, or to an id that isn't valid.
* Improve dropdown UX for internal/badges
Add a "blank" option to the dropdown to list of badges on internal/badges route.
Also add some checks to handle if an admin accidentally tries to award a "blank" badge.
* Ensure error is surfaced as flash message
* Add StimulusJS 1.1.1
Because:
- Internal will likely need more interactivity going forward
- Vanilla JS and jQuery are great, but aren't quite as organized as we
might like
- Stimulus fits our model of what internal should be (imo)
- Adopting Preact or something with templating would require rewriting a
bunch of erb (that is currently working just fine)
Stimulus is a JavaScript framework that directly compliments turbolinks
and the approach vanilla Rails takes to JavaScript. I've set it up to
specifically be used in the internal views where we are currently using
jQuery and vanilla JS. I think we should chip away at the vanilla JS
currently in place with this, which appears to be both scalable and
pragmatic exactly the sort of tool we want for building our internal
tools.
* Replace crufty article JS with Stimulus
I'm swapping out some of the stuff going on in article_script.erb with
some StimulusJS, it seems like a good test case for Stimulus.
This lets us organize the code a little more intentionally and hopefully
fixes a small performance complaint that Michael had.
* Rename uncommunicative methods
* Add unit tests for Stimulus classes
* Move Stimulus code to javascript/internal
* Add gem Ransack 2.3.0
* Add sorting and search to internal/reports
The UI here should probably be revisited sooner or later, I feel like
the vomit reactions might even need to be moved to their own view.
* Add system spec for internal reports search
* Remove filter for report_type
Michael asked that this behavior be extended to the buffer actions on
internal/listings as well.
We should probably look for an opportunity to refactor the JS currently
living in article_script.erb.
* Do not load messages in memory, just to count them
* Add Model.estimated_count
* Use Model.estimated_count in task record_db_table_counts
* Use size and estimated_count
* Use table_name so that .estimated_count works with all models
* Add comment to explain the .load.size + .each pattern
If content is unpublished it shouldn't be immediately necessary for
negative reactions to be acted on.
There is a higher touch solution here, but I'm not sure it's warranted.
* Create podcast as a user [WIP]
* Sample css for podcast form
* Nicer podcasts suggesting form
* Validate podcast feed_url
* Validate podcast main_color_hex
* Fix podcasts specs
* Fix form appearance
* Placeholder for podcast main_color_hex
* Provide a link to suggest a podcast
* Add a checkbox and a role for when a podcast is added by an owner
* Prettier checkbox in the podcasts form
* Added creator to podcasts
* Set the podcast creator
* Fix the /pod spec
* Added creator information to the internal podcast page
* Added cta class to the podcasts submit button
* Global notice when a podcast was suggested
Co-authored-by: Ben Halpern <bendhalpern@gmail.com>
* Move from env variables to SiteConfig
Related to #5384
This PR only deals with the first remaining part outlined in the issue, starting to use existing SiteConfig keys instead of the env variables.
* Restore Envfile to original version for now
* Remove console log
* Update suggest tweets layout
These changes reflect a specific request from Michael to fix the layout
of suggested tweets, including the expected border animation that occurs
on form submits for articles
* Add labels for suggested tweets
* Add a default message to badge award action
Because:
- The only badges routinely awarded manually use the same message
- Right now, unfriendly/unsafe UI can result in an error notification
The only badges that are currently awarded manually (afaik) have the
message "Congrats!!!" so for the time being, if a message is not
supplied to the UI, it will simply use the "Congrats!!!" message as a
default.
That being said, I'm not totally convinced this message won't work for
the long term. Generally, if we are awarding badges by hand, I'd imagine
we'd want a specific message explaining why we are doing that, or just
be okay with "Congrats!"
After talking with Peter about it, the longer term goal should be to
move badge messages into the database so they can be modified in the app
and not hardcoded. That also make sense regarding the effort to
genericize the app eventually.
* Test Badge notifications
* Add view for managing organizations
This adds only an index and show action for the internal/organizations
page. Eventually we'll flesh this out with features to automate the more
mechanical org management tasks.
* Use instance variable for search query
* Convert multiple expects into one
* Add pagination to organizations
* Add search spec for organizations
* Use size over count
* Move admin specs
These tests should probably be grouped together, so I moved them into a
directory called "internal"
This also encourages some additional internal tests.
* Add an internal badges controller
* Add internal view for running BadgeRewarder task
Because:
- Peter is currently running this rake task from Heroku and this is
going to make his workflow easier
- It's a step towards having a decent tool under internal for managing
badges (though I'd hesitate to call this decent)
This change adds a view and controller action to award badges in
batches, it's an improvment over the current workflow that Peter is
using, but it's still very rough around the edges.
We could definitely improve this with some error handling around the way
the BadgeRewarder works, but for now this is a net gain over how Peter
has been doing this task. I think it's worth merging as is and future
work to improve the experience and reliability of this tool can be
prioritized against other tasks.
* Add rate_limit_follow_count_daily to SiteConfig
* Add favicon_url to SiteConfig
* Add logo_svg to SiteConfig
* Add staff_user_id to SiteConfig
* Add default_site_email to SiteConfig
* Add social_networks_handle to SiteConfig
* Add ga_view_id and ga_fetch_rate to SiteConfig
* Add mailchimp newsletters IDs to SiteConfig
* Add periodic_email_digest_max, periodic_email_digest_min to SiteConfig
