* 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>
Clicking the button to follow people on search page was erroneously
triggering a reaction request, thus not having the reactable_id.
We've updated the handlers not to trigger it.
* 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
* Initial work for streaming app shell way of using serviceworkers
* Close in on serviceworker adjustment finalization
* Add docs and loading indicator
* Remove useless code
* Don't run on API
* Update app/javascript/contentDisplayPolicy/hideBlockedContent.js
* Fix small details
* Don't run serviceworker.js code in test env
* Fix JS in serviceworker
* Move private keyword to proper place in async controller
* Change shell_version to HEROKU_SLUG_COMMIT
* Update caching config
* Add test for async_info/shell_version
* 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.
* mod view form changes
* add error validation for removal tag
* add error validation to tag_list count
* re-render tag_adjustment form errors
* refactor admin delete adjusted tags form
* add prompt to tag adjustment form select
* front end validations to add/remove tag_adjustment
* allow tag_mod to undo own tag adjustment
* update/add specs
* update send spec
* update tag adjustment spec
* Add a trait for single_resource_admins to users factory
* Add single_resource_admin authrization for Growth view
* Expand GrowthController test coverage
* Add single resource admin workaround to models
* Add single resource admin to additional views
