* 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
* Remove comment spec with no examples
* Delete commented out spec
This test could be refactored to a green state, but I'm not sure it's
worth the effort.
I started down that path, but it was time consuming. It might be more
effective to rewrite this test from scratch.
For the time being, since it has not been running, I think it should be
removed from the codebase.
* 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
* Enable pending system spec
* Remove pending and useless tests
There is a pending test for functionality that does not exist, so I
removed it.
I removed some expect blocks that were essentially testing if Rspec
works / if Rails routing works. That's probably not necessary for us to
do and leaving the code in a spec encourages future contributors to
write similar specs.
* 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
We have decided enable indented-code-block because it is an expected
markdown feature. The trade-off here is that backticks will cause
rendering issues in codeblock.
* Action to request account deletion by email
* Confirmation page for user destroy
* Remove some of the old destroy user code
* System tests for user destroy
* Moved user destroy tokens to redis
* Change tests according to the new user destroy token storage (in redis)
* Added info about the link to user delete confirmation email
* Remove blank like from schema.rb
* Delete user destroy token on user delete
* Update confirm user destroy js
* Add ApplicationMetalController to relevant controllers
* Add request forgery protection to metal
* Remove logger call
* Add logger keyword and skip protect_from_forgery in test
* Uncomment main_image in test
* Add test sampler
* Use let! and let_it_be for article_spec.rb
* Regroup and restructure expectations and tests
* Move private methods in private
* Decrease the needed objects in .seo_boostable test
* Re-use the user
* Newlined
* Refactor raise_error(specific_error) expectation
The full RSpec warining is
```
WARNING: Using `expect { }.not_to raise_error(SpecificErrorClass)` risks false positives,
since literally any other error would cause the expectation to pass,
including those raised by Ruby (e.g. NoMethodError, NameError and ArgumentError),
meaning the code you are intending to test may not even get reached.
Instead consider using `expect { }.not_to raise_error` or `expect { }.to raise_error(DifferentSpecificErrorClass)`.
```
* Refactor jsitor tests to test behaviour
As pointed out by @rhymes, the previous tests were not
testing actual behaviour. This is an attempt at improving the tests.
This test was commented out, but I don't see much information in the
commit message as to why. The Pull Request which this commit was merged
from seems to be lost as well.
This test does seem to pass when it's not commented out, but there must
have been a reason it was commented out.
That being said, the test isn't really *testing* much functionality.
Essentially, it just asserts that a page with the word "settings" on it
renders from several different approaches. This might be problematic
because a false positive would be quite easy.
In light of those things, it makes sense to me that this test should be
removed.
