Wraps the parts of the notification API that allows the user to mark notifications as read.
New methods are :
- Notification.mark_as_read : marks a single notification thread as read
- Repository.mark_notifications_as_read : marks all the notifications for a given repository as read
- AuthenticatedUser.mark_notifications_as_read : marks all the notifications as read
Aims to fix : https://github.com/PyGithub/PyGithub/issues/571 and simply uses the APIs described on this page : https://developer.github.com/enterprise/11.10.340/v3/activity/notifications/
A weird thing I noticed doing this is that Repository.notifications_url doesn't seem to be usable directly. I used Repository.url + "/notifications" instead.
The Github gists api has a since parameter for the various gist searches. This adds that parameter to Github.get_gists(), NamedUser.get_gists() and Authenticator.get_gists(). Tests and replay data added/updated as needed.
I added a Time module in the tests directory, containing just a UTCtzinfo class, which I felt I needed for one of the tests (and would probably be useful in other since/until tests). Might not be the best name for the module but it seemed the least invasive thing to do.
Closes#784Closes#785
First commit fixes a small bug that I observed while trying to record some new test fixtures: the stringification of the headers is not correctly printed as a list of tuples, but as an `iteritems` object, so I forced the list evaluation.
Second commit adds the missing properties `allow_merge_commit`, `allow_rebase_merge`, `allow_squash_merge`, and `has_projects` to the `Repository` class.
Note however that I ran into some trouble while modifying the `edit` method of the `Repository` class to make use of the new properties, specifically while writing tests, so I will fix the `edit` method in a future PR.
* Added missing parameters to organisation repo creation
* team_id should already be an id not a team object
* Name arguments in the test
* Fixed assertion check
* Added missing parameters to user repo creation
* Fixed comments
This is a minor thing. It’s a convention, not a rule (obviously)—but it’s also a best practice.
Many text editors look for this kind of comment as the first line—or second line, if there is a shebang (the `#!/usr/bin/env python`, or whatever else)—and make use of this to determine the file’s encoding.
Alice GIRARD