* Create new CreateWorker
* Create new spec for CreateWorker
* Change CreateJob to CreateWorker and move to sidekiq
* Update worker
* Update priority of Reactions Create Worker
* Remove leading spaces from spec
* Add article's record key to Fastly Surrogate-Key to separate caches
After #4744 we successfully setup an auto purging system based on Fastly's surrogate key based cache and purging API.
Unfortunately this worked only in the `:show` action as comments are their own tree-based resource.
The `:index` though, is related to a single article, so without the article's record key in the `Surrogate-Key` header the first time we hit the API the result would become the value stored in Fastly's API, for all articles.
* Fix commentable mock for job spec
* Add comment.commentable.purge to the worker as well
* Add more thorough tests for commentable
* 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
* Use ancestry in the index and add test
* Add tests for show action
* Return complete comments trees for index, kill n+1 and use correct edge cache key
* Return complete comments tree for show, kill n+1 and use correct edge cache key
* Refactor tests and add surrogate keys tests
* Preload users for the whole subtree
* Clarify explanation of the edge cache keys construction
* Refactor partials
* Remove action caching
* Replace .map.flatten with .flat_map
* Fix surrogate key prefix according to Fastly docs
* Add comment.purge to Comments::BustCacheJob to use Fastly-Rails
* Fix surrogate key spec
* Ask user to add email when deleting [WIP]
* Ask to provide an email before requesting account deletion
* Additional checks to make sure that user won't be deleted w/o an email
* Revert changes on confirm destroy view
* Remove mock from specs to test the actual Suggester
* Fix articles API top articles n+1
* Fix n+1 in articles API with state parameter
* Remove eager loading for organization dashboard
* Eager load notifiables in notifications only when needed
* Algolia does not like this
* 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
A common response in collection endpoint with REST APIs is to return an empty result set when the requested params end up in an empty result. The reason for this is that the resource itself exists (the collection always exists), it just is empty.
See https://github.com/thepracticaldev/dev.to/pull/5192
* Feature 🚀 : Ability to delete messages in chat channels
- Sending message ID to frontend
- Deleting Message
- Use pusher to delete message realtime
* Minor Bug 🐞: Show message action only for current user
- User can delete or edit their own messages
* Test cases added
* Bug 🐞: Update message id for receiver
Message id was not sent to receiver by pusher
* Refactoring🛠: Message controller refactoring
* Test Cases📝 : Specs for Delete message added
* Feature 🚀 : Ability to edit messages
* Test Cases📝 : Specs for Edit message added
* Refactoring🔩: Refactoring for edit messages
* Refactoring🔩: Refactoring:2 for edit messages
* Refactoring🔩: Refactoring:2 for edit messages
* Test Cases📝 : Test Cases for edit message added
* Minor Bug 🐞: Show message action only for current user
- User can delete or edit their own messages
* Test cases added
* Bug 🐞: Update message id for receiver
Message id was not sent to receiver by pusher
* Feature 🚀 : Ability to edit messages
* Test Cases📝 : Specs for Edit message added
* Refactoring🔩: Refactoring for edit messages
* Refactoring🔩: Refactoring:2 for edit messages
* Refactoring🔩: Refactoring:2 for edit messages
* Bug Fix 🐞: Added space between edited and timestamp
Co-authored-by: Ben Halpern <bendhalpern@gmail.com>
* 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
