rreinhardt9
commented
4 years ago @wernull would you have some time to take a look at this? I figured out what was up with testing it locally... so we should be able to test the gem locally as per the README again now 👍
Remove Gemfile.lock and update Ruby
The Gemfile.lock is not a file that we want checked in with the gem. The purpose of a Gemfile.lock is to lock in a combination of dependencies for an application. In the case of a gem, we are just specifying the limits for our dependency versions in the gemspec and are not locking in a combination of dependencies (since ultimately, the application is in charge of it's own dependencies).
The only effect the Gemfile.lock has in this project is for when running it in the dummy app; is has no effect on any of the applications it's installed in. The gem should work against the latest specified in it's gemspec so there is no reason to pin the dummy app to the version in a Gemfile.lock checked into source control.
More info in this blog post: https://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
Fix patch endpoint archiving and case sensitivity
fixes #32
After a fix shipped in #29, you could no longer de-provision a user because when false was passed in as the value for active, it thought there was no value for active.
fixes #33
Technically according to the specifications, the value for op is only valid if it is one of three lower case values. However, our previous implementation accepted a case insensitive version. Because of this, we are adding backward compatibility for case insensitivity until we have a chance to properly make a breaking change and only allow lower case.
Testing Notes
You should be able to test the patch endpoint per the README and successfully archive a user now.
Here is the request I used:
where 1234 is your bearer token