Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow configuring exception level filters:true/false as a global setting for manual reporting #587

Open
erated opened this issue Apr 19, 2017 · 4 comments
Assignees

Comments

@erated
Copy link

erated commented Apr 19, 2017

Hi there,
Currently if we manually report an issue through Rollbar.error(e), if we want Rollbar to take into consideration our exception level filters, we need to add a silly flag (:use_exception_level_filters => true).

Either cancel this flag, or allow for us to set it globally as a rollbar configuration setting.

This issue just creates dirty code on our end..

jondeandres pushed a commit that referenced this issue Apr 19, 2017
Let the users to set a global `use_exception_level_filters` option

Usage:

Rollbar.configure do |config|
  config.use_exception_level_filters = true
end

By default the setting is `false` so we keep the current interface

Fix #587
jondeandres pushed a commit that referenced this issue Apr 20, 2017
Let the users to set a global `use_exception_level_filters_default` option

Usage:

Rollbar.configure do |config|
  config.use_exception_level_filters_default = true
end

By default the setting is `false` so we keep the current interface

Fix #587
jondeandres pushed a commit that referenced this issue Apr 20, 2017
Let the users to set a global `use_exception_level_filters_default` option

Usage:

Rollbar.configure do |config|
  config.use_exception_level_filters_default = true
end

By default the setting is `false` so we keep the current interface

Fix #587
@rokob rokob closed this as completed in #588 May 5, 2017
@rodeezy
Copy link

rodeezy commented Sep 18, 2024

It appears this is no longer working (its still referenced in the docs though)
UPDATE: #587 (comment)

@waltjones waltjones self-assigned this Sep 18, 2024
@waltjones
Copy link
Contributor

@rodeezy Thank you for the report.

@waltjones waltjones reopened this Sep 18, 2024
@rodeezy
Copy link

rodeezy commented Sep 18, 2024

@waltjones im so sorry, it looks like it might have been something on our end actually 🤦 . we're digging into the problem on our side to try to confirm, but we're still not too sure

@rodeezy
Copy link

rodeezy commented Sep 20, 2024

We did some local testing and it looks like the problem was on our end actually and not related to the config.
I'll post here again when our ticket goes through official QA process

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants