Ticket search results

update RAML versions

Dave Brondsema — Thu, 10 Oct 2024 14:27:16 -0000

The Allura/docs/api-rest/ files are using older versions of RAML (and json schema too). We should update those so we can use more recent raml tooling like https://github.com/raml2html/raml2html

API to list repos

Dave Brondsema — Fri, 23 Sep 2022 16:10:23 -0000

This would be helpful for a CI integration, for example

API to create projects

Dave Brondsema — Mon, 17 May 2021 15:07:02 -0000

Refactor project-import.py so that functionality can be used via a REST API

API for merge requests

Dave Brondsema — Mon, 17 Sep 2018 22:16:48 -0000

REST API for User Activity does not work due to missing attribute

Rohan Verma — Mon, 11 Jul 2016 15:10:45 -0000

Eg. https://forge-allura.apache.org/rest/u/brondsem/activity returns 500 This is due to line 227 since shortname attribute is not set for Profile tool. What should I do to solve it? I'm not sure what needs to be done. ~~~ 'following': data['following'], 'followee': { 'activity_name': data['followee'].shortname, 'activity_url': data['followee'].url(), 'activity_extras': {}, ~~~

Add author profile picture information to the post inside response from the API

Rohan Verma — Mon, 23 May 2016 19:07:22 -0000

I was experimenting with the API on https://jsfiddle.net/r4jg82fr/ and found that it would be useful to supply the profile photo url in the response(eg https://forge-allura.apache.org/rest/p/allura/tickets/_discuss/thread/2abc9fd7/) along with each post. Since, getting it via another ajax such as https://forge-allura.apache.org/rest/u/brondsem call would be expensive. Also, users who have set the image to be fetched from gravatar have it set to null. (eg. https://forge-allura.apache.org/rest/u/rhnvrm)

Update Allura api docs with new admin endpoints

Heith Seewald — Fri, 15 Jan 2016 19:15:44 -0000

Several endpoints have been modified or added with the merge of [#7919]. We should update and republish our docs to reflect those changes.

API for current site notification

Dave Brondsema — Wed, 27 Jan 2016 17:43:01 -0000

Expose the current site notification (i.e. `ThemeProvider.get_site_notification` logic) as an API. The `request.cookies` might be able to stay as it is, but likely should support those values being passed in as regular API params. The `response.set_cookie` probably should be returned as response values. Make sure the RAML api docs are updated.

Move the _nav.json endpoint into the /rest/ namespace

Heith Seewald — Fri, 14 Aug 2015 14:22:59 -0000

We should move ** /p/{project}/_nav.json** to **/rest/p/{project}/_nav.json** and update our RAML docs to include this endpoint. We also may want to remove the .json or rename the endpoint to be more consistant with the rest of our endpoints.

Update Api to support JSON for POST endpoints

Heith Seewald — Fri, 14 Aug 2015 14:10:31 -0000

Update POST api endpoints to accept json in addition to x-www-form-urlencoded. The RAML docs will need to be updated as well.

Improve git/hg/svn endpoints for rest api

Heith Seewald — Fri, 20 May 2016 21:04:45 -0000

Our rest api endpoints for git/hg/svn need to be cleaned up. Currently they are too simplistic (svn isn't even hooked up). Our RAML api documentation should be updated as well. It might be easier to update the RAML first to ensure a consistant and reusable interface that can then be implemented in code.

API endpoints error when using access_token as URL param

Dave Brondsema — Mon, 24 Aug 2015 14:29:36 -0000

`TypeError: has_access() got an unexpected keyword argument 'access_token'` This may also be true for many of our other API endpoints. We should just be able to add `**kw` to the python controller methods.

Limit the "_discuss" results from the tickets api.

Heith Seewald — Mon, 05 Oct 2015 13:59:37 -0000

Currently, [this](https://forge-allura.apache.org/rest/p/allura/tickets/_discuss/) api endpoint for allura returns a 200k line (when formatted) json responce. We should evaluate the need for the existance of the endpoint. If we need it, we should paginate the results.

Publish our RAML files

Dave Brondsema — Mon, 10 Aug 2015 14:28:26 -0000

As followup to [#6797] we should find some way to publish our RAML files. E.g. as static HTML pages, and/or as a live demo so people can try it out.

Enable CORS access to rest APIs

Dave Brondsema — Mon, 27 Jul 2015 14:35:17 -0000

Original request: https://sourceforge.net/p/forge/feature-requests/426/ May need `.ini` settings if this is something that some sites would want and not others.

Tracker stats 500 error when accessed via the allura-api

Heith Seewald — Thu, 23 Apr 2015 18:51:19 -0000

works: https://forge-allura.apache.org/p/allura/tickets/stats/ does not work: https://forge-allura.apache.org/rest/p/allura/tickets/stats/ The rest version of a tracker's stats page expects `/rest/p/allura/tickets/`**{ticket_num}**. The endpoint `/rest/p/allura/tickets/`**stats** causes the rest handler to use `stats` as the `ticket_num` -- resulting in a 500 error.

Support Authorization header for OAuth

Igor Bondarenko — Thu, 20 Aug 2015 22:06:09 -0000

Most of the work was done in [#7832]. Just need to update it according to spec: [discussion](https://forge-allura.apache.org/p/allura/tickets/7832/#3e53)

APIs to manage webhooks

Dave Brondsema — Thu, 20 Aug 2015 22:06:09 -0000

We should support APIs to manage webhooks so that 3rd-party sites can use oauth to configure a webhook on behalf of a user. This is a common practice to make it easier for the user.

Return more fields in ticket API search results

Dave Brondsema — Thu, 20 Aug 2015 22:07:00 -0000

On ticket search API results, only the "summary" and "ticket_num" fields are present. We should include many more, if not all fields that solr has available. That will allow API clients to get information in a single request instead of fetching every individual ticket to get whatever data is needed.

API for has_access

Dave Brondsema — Thu, 20 Aug 2015 22:06:09 -0000

It would be useful to have an API to run `has_access` permission checks so that 3rd-party clients can rely on Allura permissions. I think that it would be an API per-tool and per-project including neighborhood-projects (whose API needs some fixing) and that you would need 'admin' access on the project to use the API. It could take a username and role and return a true/false result.

API cleanup: rename `app.has_access` to indicate it is mail-specific

Dave Brondsema — Mon, 09 Mar 2015 16:00:48 -0000

Almost all `has_access` usage is from helpers and security packages. The `app.has_access` method is used for mail tasks: `Allura/allura/tasks/mail_tasks.py:59: if not app.has_access(c.user, userpart):` And documented in the first paragraph of https://forge-allura.apache.org/docs/platform_tour.html#email-integration I think it should be named something different (and fall back to `has_access` for backwards compatibility)

DOAP API for projects

Dave Brondsema — Thu, 20 Aug 2015 22:07:00 -0000

Create a [DOAP](https://github.com/edumbill/doap/wiki) API endpoint for allura projects. I think the URL should be /rest/p/projectname?doap (open to better suggestions). It should be XML that is similar in format to SourceForge (classic) DOAP files like https://sourceforge.net/api/project/name/vivo/doap as much as possible. A number of fields in that are not applicable to Allura, so just don't include them. It is okay for Allura DOAP to continue to use some of the "sf" namespace elements like environment, database, etc (those are all the trove types of a project), as well as sf:awarded (for awards, use the current Allura award system available via neighborhood admin pages). `` is for each project Admin and `` is for each Developer on the project. In addition to the basics, each tool should be able provide its own XML/RDF data to include. For example, SourceForge's internal mailman tool could provide `` entries and Files tool could provide a `` entry.

Better ordinal options for install tool API

Dave Brondsema — Thu, 20 Aug 2015 22:07:10 -0000

The install_tool API doesn't have any options for setting the order of a new tool. (And the hard-coded calculation for 'ordinal' uses `len(installable_tools)` which isn't correct so the ordinal ends up kind of random). Options I think we should have: * last: make it last * first: make it first * alpha_tool: sort it alphabetically amidst the tools of that type already installed. I think it's fair to assume the rest of the tools are already sorted, so can just loop through them until you find one where the name comes later, and then insert before that. There are lots of possibilities, but alpha_tool is primary use case at the moment.

Include bulk_export_download_instructions in export API result

Dave Brondsema — Sun, 29 Mar 2015 18:10:16 -0000

The `bulk_export_download_instructions` text that is included in emails after an export should also be included in the success API result for a bulk export. Then users of the API will have instructions handy and not have to do a manual export to get them via email.

Export API's tools params should be optional

Dave Brondsema — Mon, 30 Jun 2014 20:33:52 -0000

Make the Tools parameter when scheduling an export job optional and export all existing when it is missing, otherwise the backup Script needs to be changed every time a tool is added and manual things to do usually are forgotten regularly.