As part of my reading and seeking to understand the
`Articles::Feed::LargeForemExperimental` class, I figured I would come
in and add parameters. In adding parameters, one thought I had was that
we can more readily create a data structure that allows us to tweak the
various implicit values.
This is a first step to help me understand and name the numbers.
This is the counter-argument to #15152 - filter in the controller
rather than adding lots of conditional logic to the view to handle the
case where there was a vomit reaction left for a deleted user causing
the moderation reports page to fail to load.
* feat: add a required attribute for the fields on Navigation Links that are required
* remove the weird margin
* we want the field to be required only when we don't have a vallue from form.object[:icon] that is in the craete view
* feat: add type button
* feat: open up the username field is we press keydown on the edit username element
* fix: remove the keypress
* fix: add type: button to the password field
* trigger github hooks
* rough starting point, roving tabindex in toolbar, bold and italic buttons
* refactor, add link
* add ul
* add ordered list
* core formatters in place, wip
* overflow options
* add keyboard shortcuts
* tidy up some dodgy classes
* add mocks for runtime in test and storybook, use correct modifier key for tooltip
* style tweaks
* refactor tooltips
* add markdown formatters tests
* add tests for toolbar component, fix mistake in overflow menu tooltips
* undo change no longer needed to button
* fix issue accessing runtime in formatters file
* only show darkened buttons and tooltips when focus-visible is true
* mobile view
* fix for responsive buttons & roving tabindex
* tweaks from PR review
* update cursor position on link insertion
* add a new line after block selection formatting
* align icons in center
* tidy up overflow menu listeners
* small refactors
* test for new text area util
* tidy up new lines after syntaxes
* fix logic in cursor offsets for links
* prevent scroll jumps after inserting syntax
* some style tweaks
* insert level 2 heading with new lines above and below
* update icons
* use margin instead of gap
* Fix and clean up podcast pages
* Adjust tests
* Fix a test
* Fix missing i18n
* Fix tests
* Fix tests
* Fiddle with test
* Sure up css and tests
* Add featured as allowed param
* Fix a couple tests
* xit out test
* Update app/views/podcast_episodes/index.html.erb
* Update app/views/podcast_episodes/index.html.erb
Co-authored-by: ludwiczakpawel <ludwiczakpawel@gmail.com>
Co-authored-by: ludwiczakpawel <ludwiczakpawel@gmail.com>
Turns out this caused a *different* problem. It would work for the first
delete batch in `BulkSqlDelete`, but subsequent `DELETE` queries would
then get their `statement_timeout`s reset to the global setting. The
issue was that `BulkSqlDelete` uses methods that don't respect nested
transactions, and we were already resetting the value of the setting to
its previous value anyway, so there was really no reason to run it
inside a transaction.
The only failure mode I know of here is that the `ensure` block breaks
because `connection` is severed. In that case, the value is reset anyway
when the connection pool replaces the connection so the failure does not
propagate.
* Allow Emails::RemoveOldEmailsWorker to run longer
We set the SQL statement timeout based on the STATEMENT_TIMEOUT
environment variable (defaulting to 2.5 seconds in production), but not
all SQL queries are created equal. Since some may take longer out of
necessity, this PR introduces a `Model.with_statement_timeout` method
that allows you to change the SQL statement timeout only for a given
block.
* EmailMessage doesn't inherit ApplicationRecord
It inherits from `Ahoy::Message`, which inherits directly from
`ActiveRecord::Base`.
[3] pry(main)> EmailMessage.ancestors
=> [EmailMessage(id: integer, clicked_at: datetime, content: text, feedback_message_id: integer, mailer: string, sent_at: datetime, subject: text, to: text, token: string, user_id: integer, user_type: string, utm_campaign: string, utm_content: string, utm_medium: string, utm_source: string, utm_term: string),
EmailMessage::GeneratedAssociationMethods,
EmailMessage::GeneratedAttributeMethods,
Ahoy::Message(id: integer, clicked_at: datetime, content: text, feedback_message_id: integer, mailer: string, sent_at: datetime, subject: text, to: text, token: string, user_id: integer, user_type: string, utm_campaign: string, utm_content: string, utm_medium: string, utm_source: string, utm_term: string),
Kaminari::ConfigurationMethods,
Kaminari::ActiveRecordModelExtension,
Ahoy::Message::GeneratedAssociationMethods,
Ahoy::Message::GeneratedAttributeMethods,
Bullet::SaveWithBulletSupport,
ActiveRecord::Base,
...
* Use milliseconds to match STATEMENT_TIMEOUT units
* Fix notifications not deleting because mentions already destroyed
* Fix spelling in spec
* Use rspec expect/to assertions for delete notification spec clarity
* resolve failing spec, and remove need for environment check 🎉
* When a user is blocked from commenting on an article, show correct error message
* Created new error type ModerationUnauthorizedError and changed error text for it
* I18nize nav_menu's list items
* reverted changes to admin list item in attempt to pass the one failed test in Travis CI
* Update reading_list value
Co-authored-by: Michael Kohl <citizen428@forem.com>
It's confusing why we set model as the block binding, but still access
user from the method argument (reaching outside the `tap` block).
Within this block, use model consistently to name the user.
Only change the user variable, not _user_ within methods
* Translation for "on Video"
* Moving dashboard.loading to core.loading to keep code DRY
* Translations for views/videos/new.html.erb
* Reverting the changes on app/views/dashboards/_sublist.html.erb
* Adding the dashboard.loading translations back
* Fixing some merge conflicts + sorting the dashboard translations
* Fixing the contact text on views/videos/new
* Using the full path instead of the lazy load
* Fix rotation of images uploaded from iPhones
iPhones[1] take pictures in portrait mode with the orientation set to
90ºCCW. We noticed that uploading one of these images to a Forem
instance caused the image to be rotated when rendered. The current
theory is that Imgproxy is not maintaining the orientation value when
processing, which is solved by setting `auto_rotate: true` (serialized
into the Imgproxy URL as `ar:1`), according to the documentation.
See: 8e6585e28d/docs/generating_the_url_advanced.md (auto-rotate)
[1] This probably happens with other phones, but we discovered the issue
using an iPhone.
* Fix Imgproxy URL expectation for auto_rotate
