-
-
Notifications
You must be signed in to change notification settings - Fork 873
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
Flesh out Dashboard Endpoints #1836
Comments
If someone with the power to can, please assign this to me 😄 @studioj |
jpavlav
added a commit
to jpavlav/jira
that referenced
this issue
Mar 17, 2024
* Make method name align with parameters/ui
jpavlav
added a commit
to jpavlav/jira
that referenced
this issue
Mar 17, 2024
* Make method name align with parameters/ui
jpavlav
added a commit
to jpavlav/jira
that referenced
this issue
Mar 17, 2024
* Change name of `Gadget` to `DashboarGadget` for specificity and clarity. Could be `gadget`'s of other kinds might exist in the future. * Updated `gadgets` method name to `all_dashboard_gadgets`. More in line with what it does, plus adds the `dashboard` context to the method.
jpavlav
added a commit
to jpavlav/jira
that referenced
this issue
Mar 19, 2024
* Created `NotJIRAInstanceError` exception. This is raised in the case one of the convenience decorators utilized on a client method is improperly applied to some other kind of object. * Moved the `cloud/experimental` decorators into `client`. They are technincally utilites for the `client` so I think this makes sense logically. It also solves the issue of circular imports that came up when attempting to do a type check on the instance that is passed into these decorated functions. * Updated `cloud` decorator name to `cloud_api` to make it clearer. * Updated `experimental` to `experimental_atlassian_api`, to make it apparent to a developer that the `experimental` aspect of the decorated method is on the `atlassian` side of things, not on our side. * Updated docstrings where `ResultList`'s are being returned to include the kind of resource that is stored within the `ResultList`. * Updated `copy_dashboard` and `create_dashboard` function signatures. `edit_permissions` and `share_permissions` default values are no longer `list`'s to avoid the issues with mutable default argument evaluation. Now they are set to `None` by default and within the methods, they are defaulted to `[]` in the case that they evaluate "falsey". * Made `_get_internal_url` docstring more representative of what it does. * Ensured return types on the `update` methods of the `DashboardItemProperty` resource and the `DashboardGadget` is correct. * Added `only_run_on_cloud` marker to skip a test if it should only run during cloud tests to `conftest`. * Updated `test_dashboard` to utilize `only_run_on_cloud`. * Moved tests of `cloud_api/experimental_atlassian_api` decorators into the `test_client` file. Refactored those tests a bit.
jpavlav
added a commit
to jpavlav/jira
that referenced
this issue
Mar 20, 2024
* Added necessary path regex/class mapping to `resource_class_map`. * Updated the `test_generic_resource.py` tests to include the resolution of those new paths, their regex, to the appropriate class.
jpavlav
added a commit
to jpavlav/jira
that referenced
this issue
Mar 20, 2024
Included some `isinstance` assertions in the `Dashboard` tests per @adehad's request.
adehad
pushed a commit
that referenced
this issue
Mar 22, 2024
`jira/client.py` ---------------- * Added `cloud_api` convenience decorator for client methods that make calls that are only available on the `cloud_api` api. It checks the `client` instance to see if it `_is_cloud`. If not, it logs a warning and returns `None`. This was the convention seen on other endpoints on the `client`. * Added `experimental_atlassian_api` convenience decorator for client methods that make calls that are experimental. It attempts to run the client method, if a `JIRAError` is raised that has a response object, the response is checked for a status code in `[404, 405]` indicating either the path no longer accepts the HTTP verb or no longer exists, and then logs a warning and returns `None`. Otherwise it re-raises the error * Imported `DashboardItemProperty`, `DashboardItemPropertyKey`, and `DashboardGadget` resources to client for use in new methods. * Updated the `dashboards` method to include the `gadgets` that exist on a given dashboard. This is a logical association that makes sense, but isn't directly exposed in the API. * Added `create_dashboard` method. It creates a dashboard via the API and returns a `Dashboard` object. * Added `copy_dashboard` method. * Added `update_dashboard_automatic_refresh_seconds` method. This calls the `internal` API, which is why it's decorated with `experimental_atlassian_api` and `cloud_api`. This might change in the future, but it really is a handy thing to have, otherwise, the user has to configure this in the web interface. --- * Added `dashboard_item_property` method. This is available on both `cloud_api` and `server`. * Added `dashboard_item_property_keys` method. This is available on both `cloud_api` and `server`. * Added `set_dashboard_item_property` method. This is available on both `cloud_api` and `server`. --- ^^ These methods all provide a means of adding arbitrary metadata to `dashboard_items` (`gadgets`) and/or configure them via specific keys. * Added `dashboard_gadgets` method. This returns the gadgets associated with a given dashboard. It also iterates over the `keys` for this `gadget`'s properties, generating a list of `DashboardItemProperty` objects that are associated with each gadget. This makes it really easy for the user to associate which configuration/metadata goes with which gadget. * Added `all_dashboard_gadgets` method. This returns a list of from `jira` of all the `gadgets` that are available to add to any dashboard. * Added `add_gadget_to_dashboard` method. This allows the user to add gadgets to a specified dashboard. * Added the protected method `_get_internal_url`. This is very similar to `get_url` or `get_latest` url, where `options` are updated to allow for easy resolution of paths that are on the `internal` `jira` api. * Updated the `_find_for_resource` typehint on `ids` because it is possible that a resource requires more than `2` ids to resolve it's url. jira/resources.py ----------------- * Added the new resources `DashboardItemProperty`, `DashboardItemPropertyKey`, and `Gadget` to the `__all__` list so they are represented. * Added a `gadgets` attribute to the `Dashboard` resource to house `gadget` references. * Added `DashboardItemPropertyKey` resource. * Added `DashboardItemProperty` resource. The `update` and `delete` methods are overridden here because it does not have a `self` attribute. This is kind of in an in between space as far as being considered a resource, but for ease of use as an interface, it makes sense for it to be considered. * Added `DashboardGadget` resource. It too has overridden `update` and `delete` methods for the aforementioned reasons. jira/utils/__init__.py ---------------------- * Added `remove_empty_attributes` convenience method. I found myself having to remove empty attributes or add a lot of branching in order to accommodate optional payload parameters or path parameters. This function made that easier. jira/utils/exceptions.py ------------------------ * Created `NotJIRAInstanceError` exception. This is raised in the case one of the convenience decorators utilized on a client method is improperly applied to some other kind of object.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem trying to solve
I have a project at work where we are creating and updating dashboards dynamically. This is the library we primarily use for interacting with Jira in our
python
code, so I figured it makes sense to expose those endpoints if possible.Possible solution(s)
The solution I came up with is to create the appropriate calls in the
client
and the correspondingresource
s as well to flesh out this functionality. Per @studioj, I've been conscious of the fact that these calls are both only available in thecloud
and many are consideredexperimental
.Alternatives
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: