* feat: define the different social media handles
* feat: dynamically render all the social media fields
* feat: ensure that the social media handles are permitter and dealt in a separate path from the rest
* test: update social_networks_handle to social_media_handles
* feat: update the sidebar to use different social media
* feat: update the twitter:site meta handle to be SiteConfig.social_media_handles["twitter"]
* feat: update the a links to tweets
* feat: make the links dynamic and only show those that there is a value for
* refactor: make @ThePracticalDev dynamic
* refactor: make @ThePracticalDev dynamic
* feat: add dynamic social media handles
* chore: rename values
* chore: remove extra social handles
* chore: some spacing
* chore: remove lines
* rafector: user rails-settings-cached type: :hash to set the type and the defaults
* feat: use nil and blank instead of "" and empty
* chore: move the social media handles into the right box
* refactor: rearrange model placement based on the UI
* chore: code climate
* refactor: comments from PR
* chore: rename the ff
* chore: amended twitter username
* chore: add a temporary rake task
* feat: update names
* chore: why am i using the old syntax :(
* chore: revert dynamic erb variable in offline.html
* Work in Progress
* Time for Refactoring
* WIP Implementation, still lacking tests
* Incorporate PR feedback from team
* Working now
* Add specs specific to JSON being returned by "update" action
* Refactors and Bug-Fixes from PR review
* Remove variants from backend portion of onboarding
Since we're no longer using variants in onboarding, we don't need this code anymore!
* Ignore unused column on user, onboarding_variant_version
* Add community_member_description, tagline and mascot_image_url to SiteConfig
* extra space
* Add mascot_image_description field to SiteConfig
* Fix test
* Add audit logging for negative reactions
This change saves requests that create negative reactions to the audit
log. We need to be monitoring admin and moderator actions throughout the
app to increase visiblity on how our tools are being used and identify
abuse.
Additionally, this will help east concerns about giving elevated users
more powerful tools.
* Add a basic UI for moderator audit logs
* Log experience level ratings
* Log tag adjustments
* UI tweaks for moderator actions log
* Add logging to internal reactions controller
* Add logging for admin actions on users and articles
* Add searching to the moderator actions table
* Move audit instrumentation out of concern
We are able to use a PORO here instead of using a Rails concern. Moving
this also makes syntax to audit something quite a bit more explicit and
obvious to future developers
* Change moderator logs pagination page length
* Move auditing to after action filters
* Add moderator actions to the internal navbar
* Add request spec for internal moderator actions
* Use request params to populate AuditLog slug
* Add a table for moderator reactions
This is a simplified version of a feature that should be fleshed out
in the near future.
Despite the fact that this project is taking a new direction, I think
this table could be useful in the meantime.
* Add specs for internal mod actions view
* Rename mod actions to negative reactions
* Create primary_sticker_image_url in SiteConfig
* Adding test for updating primary_sticker_image_url
* typo
Co-authored-by: Ben Halpern <bendhalpern@gmail.com>
* Add internal response template controller
* Add response template policy and spec
* Add response template views for internal
* Add missing html oops, and some padding
* Use arrays instead of %w because spaces
* Link to user in index list
* Add actual HTML oops
* Allow success flash to be displayed
* Add tag moderator trait
* Remove unnecessary .all
* Use constant to avoid duplication
* Use URL helpers over manual string URLs
* Use appropriate renders and URLs
* Follow conventional CRUD and use form_with
* Add internal request spec for response_templates
* Add missing view file oops
* Use table view for index and bootstrap styles
* Redirect to index after create
* Use clearer messaging for labels
* Validate email types to use only plain text and html
* Remove unused CSS rules
* Use bootstrap utility class over custom css
* Fix grapical bug with buffer tags
* Fix internal UI highlighting and misc fixes
This commit is a little bit too big.
It fixes a bug with the internal UI that was breaking the highlighting
feature (indicates status of articles and when an AJAX request has been
made).
It also does some reformatting in the internal listings UI. This should
make it a bit easier on anyone writing buffer updates in the listings
UI. I was able to reapply some stimulus I wrote previously for this,
super easy!
There are also a couple of CSS classes I renamed to match Bootstrap's
naming conventions.
* Remove <br> tag
* Update article_controller Stimulus test
The navbar in internal is a bit too much for a horizontal nav.
Because we aren't using breadcrumbs, it also indicates to users where
they are, so it needs to be visible and not collapsed.
Making this a sidebar fixes both of those problems. In this state, it is
definitely a barebones implmentation, but it is also an improvement over
the hornizontal nav.
Co-authored-by: MichaelaHunter <michaela1234@gmail.com>
Co-authored-by: MichaelaHunter <michaela1234@gmail.com>
* Break feedback_messages view into partials
* Standardize capitalization
* Add visual cues for banned and vommitted users
* Use helper methods to construct urls
* Rename vomitted? to vomitted_on?
vomitted_on? is a slightly more clear method name. This change takes
Rhymes' suggestion to use the AR method exists? over where(...).exists?
* 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.
