-
Notifications
You must be signed in to change notification settings - Fork 64
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
Api docs #142
Merged
Merged
Api docs #142
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ApplicationList has some custom data columns that require the group_type and group_id values, which can't be passed through except as part of the path, at least in my experimentation. This works, although it's not ideal. After updating to the newer Datatableview version and API I'll try again.
The datatables don't seem able to (without fooling around with them) to retain the querystring values that are needed for filtering by machine_group, business_unit, etc. This is due to generating the lengthy querystring required for datatables and just replacing the request's querystring. Since the REST API is separate, and the views here need to only work through the web app, AND we will never NOT want to filter by some group (even 'all'), I restored the group_type and group_id values to the URL paths. These are hardcoded and won't have any issues like filtering inventory items by install path. This also migrates to the new datatableview API, which splits up the concept of a datatable from the actual view class that depends on it.
Adds: - inventory_exclusion_pattern - filter_proxied_virtualization_apps
`HasRWPermission.has_object_permission`, at least on current DRF, is never called. Moved to `HasRWPermission.has_permission` and expanded to handle all three authentication possibilities: (a Sal User, AnonymousUser/no auth attempted), an ApiKey. Also do some minor cleanup.
Rather than specify identical auth and perm classes on each view, set them once at the global level. Also, remover some boilerplate comments that are not needed.
This is required now; either fields or excludes (or inherited through other serializers). This gets them all working. More work could be done to determine whether we actually want to return all fields!
The DRF docs site does syntax highlighting with pygments and makes use of markdown if it's available.
This looks good, I will test when I get a chance. 🙇 |
This commit moves machine/full machines, business units, and machine groups. This uses a SimpleRouter, although once everythings gets moved, a DefaultRouter would be in order. It also restores some of the (seemingly intended) nested values on *full* machines, e.g. facts, conditions, etc. This allows you to create MachineGroups by specifying an ID for business units. May switch to hyperlinked identities later.
Fix broken img url for product icon
Update machine_detail
Multiple report formats
Don't tie ourselves to System Profiler's format.
…gations != searches could sneak through and not be negated
fix multiple dictionary in array conditions.
…th_fix Inventory app path fix
Broken client reporting
…rch_maint-fix making search_maint.sh path independent
This commit also creates an alias for existing URL routes to go to the v1 API. Once it's time to switch to v2 as the default, we can just change the alias.
This is why we test!
Okay, I would say this is about as far as I can go on this for the time being. To run the tests, activate the venv and do |
Alrighty, I will crack on with testing. |
This looks fantastic. I'm going to verify over the next couple of days that all of my integrations on the old api still work, then I'll merge this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is not finished, but I thought I would make this easily visible and start the PR.
This PR is to enable the (already) included django-rest-framework docs site for Sal. Graham has already done the vast majority of the API setup work. This just cleans that work up and updates things to use the new docs site and handle authentication and permissions.
Done:
api
url (api/docs
).TODO:
In case it's not immediately obvious, when you go to the api/docs site, if you're already authenticated to Sal, you'll see authentication: session in the bottom lefthand corner. You can also go straight to this and login if you haven't done so already.
Also, you can switch the code examples to python down there.