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

Api docs #142

Merged
merged 120 commits into from
Feb 6, 2018
Merged

Api docs #142

merged 120 commits into from
Feb 6, 2018

Conversation

sheagcraig
Copy link
Contributor

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:

  • Update requirements file to include new django-rest-framework and docs dependencies (pygments and markdown).
  • Enable docs site entirely under the api url (api/docs).
  • Web browser access to existing api endpoints will serve an interactive documentation page as well.
  • Refactor custom authentication and permissions classes to handle the three possible situations: a Global Admin user, an API Key request, or an Anonymous User with no auth attempted.
  • Update serializers to django-rest-framework 3.6's API.

TODO:

  • Write docstrings (they get pulled into the doc site automagically)
  • Confer with @grahamgilbert and anyone else about the included columns for results.
  • RTFM and audit the existing serializer / view structure to as elegantly as possible express all of the things we want to be available.

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.

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.
@grahamgilbert
Copy link
Member

This looks good, I will test when I get a chance. 🙇

sheagcraig and others added 16 commits September 8, 2017 16:22
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
Don't tie ourselves to System Profiler's format.
…gations

!= searches could sneak through and not be negated
fix multiple dictionary in array conditions.
grahamgilbert and others added 25 commits January 19, 2018 08:35
…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.
@sheagcraig
Copy link
Contributor Author

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 manage.py test api

@grahamgilbert
Copy link
Member

Alrighty, I will crack on with testing.

@grahamgilbert
Copy link
Member

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.

@grahamgilbert grahamgilbert merged commit 15ba230 into salopensource:master Feb 6, 2018
@sheagcraig sheagcraig deleted the api_docs branch February 8, 2018 17:19
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

Successfully merging this pull request may close these issues.