-
-
Notifications
You must be signed in to change notification settings - Fork 271
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
Raises on INSUFFICIENT_PERMISSION error from NetSuite response #405
base: master
Are you sure you want to change the base?
Raises on INSUFFICIENT_PERMISSION error from NetSuite response #405
Conversation
b0c8481
to
dcdbaa4
Compare
Hey @iloveitaly , could you comment or merge this PR? I have similar issue and I think more people are affected by this.. |
@iloveitaly thanks! we could add feature flag, so it would not break old implementations. |
@iloveitaly any updates? Would love to see this merged! |
@JakubKopys not yet :( Pretty busy with the day-job at the moment. |
Feature flag is probably a good idea as this might cause unexpected exceptions for people using this gem. I'm happy to implement the flag! One option is to have simple boolean config to
|
case response_error_code | ||
when 'INSUFFICIENT_PERMISSION' | ||
raise NetSuite::PermissionError, status_detail[:message] | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aom what other error types do you think would be added to this switch statement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iloveitaly I don't know yet :) By implementing switch-statement I wanted to embrace the possibility of handling more errors that should raise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://netsuite.custhelp.com/app/answers/detail/a_id/11613 I see a lot of error types, but I don't know which will be useful here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems my user account doesn't have access to that link.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nevermind. I had to open SuiteAnswers from NetSuite Help so it authenticated me and I was able to open the link directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Included list to the documentation as a comment in raise_on_response_errors
method.
In my use case I've burned myself with INSUFFICIENT_PERMISSION errors often enough that I wanted it to raise instead of fail silently. I can't say whether other error codes should raise but I assume someone might have a good case to add more of them to this list in future!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iloveitaly @aom This makes good sense to me. Though I would think that we wouldn't want to fail silently for any unsuccessful requests.
Would it be useful to have a "generic" ResponseError raised for all other error types and then we could add to the list of specific errors as needed?
def raise_on_response_errors
return unless response_error_code
case response_error_code
when 'INSUFFICIENT_PERMISSION'
raise NetSuite::PermissionError, status_detail[:message]
else
raise NetSuite::UnsuccessfulResponseError, "#{status_detail[:code]}: #{status_detail[:message]}"
end
end
I don't know if it would be awkward to have have a mix of specific and generic errors raised
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I realize that this PR has been open for a while. Adding the generic error could definitely be done in a second phase so it doesn't hold this one up any longer.
I think this is right approach. Although I would use only
|
Update fork
@freezepl Agreed. As long as we're only handling one response error it should not be any more complicated to turn the feature on. I did the gate now. I think I'll need to update this to README.md next if this is what we'll want to merge? |
Thanks @aom this looks awesome! Ideally this option should be a default one, but it is a breaking change. It could be released under @iloveitaly what do you think about this PR now? |
Why should we gate this behind a feature flag? Given that this is less than < 1.0 I don't see any reason why we can't introduce breaking changes, especially if we document them in the release notes. I think raising an exception on these sort of hard NetSuite failures feels like the correct default behavior and I can't imagine a world where folks wouldn't want an exception to be raised. Let me know what I'm missing here! |
@iloveitaly you commented here about Maybe we can do it other way round ? Turn it off in configuration? |
How about this: With Then at 1.0 you could change the default to true and add it as a breaking change to release notes? There could be a simple PR labeled with 1.0 for this change. |
I agree with @iloveitaly that these sort of hard NetSuite failures should raise instead fail silently. It would've been especially helpful when we we're setting up the access management for our project :) But including it in |
@iloveitaly any updates on this PR? Can we merge it? |
Bump! Guys would like to use this feature and I don't want to use fork. Can we merge it? @iloveitaly |
@iloveitaly any thoughts ? |
@iloveitaly can we merge this PR ? |
Sorry, haven't had time to look at this! I need to run some tests on other systems first. Not a priority at the moment, unfortunately :( |
7185ffc
to
df796ee
Compare
5 moths later @iloveitaly could we do something about this PR ? (after fixing conflicts) |
8deebe2
to
940278f
Compare
@freezepl @iloveitaly Rebased with master to resolve conflicts. |
I'm no longer maintaining the fork. Best people to have a chat about changes to this PR are @beyondcompute and @edimossilva |
We're handling a NetSuite installation with multiple Subsidiaries and during development we're seeing a lot of INSUFFICIENT_PERMISSION errors from Subsidiary restrictions. Especially when
search
ing for subsidiaries from NetSuite.In development these are easy to spot from XML responses but in production they would get lost without verbose logging. We consider these the kind of errors to raise because they won't heal themselves automatically.
Example SOAP request and response:
Response