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

Flesh out Dashboard Endpoints #1836

Closed
jpavlav opened this issue Mar 12, 2024 · 1 comment · Fixed by #1837
Closed

Flesh out Dashboard Endpoints #1836

jpavlav opened this issue Mar 12, 2024 · 1 comment · Fixed by #1837

Comments

@jpavlav
Copy link
Contributor

jpavlav commented Mar 12, 2024

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 corresponding resources as well to flesh out this functionality. Per @studioj, I've been conscious of the fact that these calls are both only available in the cloud and many are considered experimental.

Alternatives

No response

Additional Context

No response

@jpavlav
Copy link
Contributor Author

jpavlav commented Mar 12, 2024

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.
@adehad adehad linked a pull request Mar 20, 2024 that will close this issue
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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant