Ticket search results

What is the DocumentRoot of Allura Installation - Centos 7 - PHP 5.4

Alexander Liebrecht — Mon, 21 Mar 2016 15:06:45 -0000

Hello Developers, I would like to work with hosted Allura itself and not find out loud to DocumentRoot as the paths. I sit on Centos 7.0 and PHP 5.4 and mySQL latest version. In FTP account I have the directory **/allura/allura** and in the directories like /ForgeBlog, /ForgeChat, /ForgeDiscussion and so on. My vHost entry in the httpd.conf file looks like this: ServerName allura.alexl.eu ServerAdmin root@allura.alexl.eu DocumentRoot /var/www/allura/allura Options +Indexes +FollowSymLinks +MultiViews AllowOverride All Require all granted CustomLog /var/log/allura/access.log common ErrorLog /var/log/allura/error.log But something does not seem to agree and I do not know what needs to be entered for DocumentRoot in vhost. Can you possibly help me there, because otherwise I do not get ahead ?! I thought that Allura is called in web browsers under **/allura**, but I have after installation via the console directory **/allura** and in the directories **/allura** and **/env-allura**. Is that correct or so I have to move a little. I still do not know whether I have placed all Allura content properly. At least I followed a good guide on the official Allura website. What can you tell me about my problem? Thanks in advance.

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.

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.

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.

Api to install a tool

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

We should have an API to install tools. Among other things, make sure an audit log entry is created. Include simple docs that we can add to https://sourceforge.net/p/forge/documentation/Allura%20API/

Move API docs from sf.net wiki to Allura (with raml?)

Dave Brondsema — Mon, 24 Aug 2015 14:30:22 -0000

Right now the allura API docs are at https://sourceforge.net/p/forge/documentation/Allura%20API/ They should be moved to Allura itself. We should also consider writing the API docs with [RAML](http://raml.org/) which looks very nice to me. Simple and readable, has composition for things like "pagination" which apply to multiple endpoints. With RAML we could also show interactive documentation with "try it live" functionality at http://www.apihub.com/

Expose votes on Ticket json format

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

The Tickets API should expose the number of up and down votes. This should be part of all VotableArtifacts' json methods, so that other votable artifacts have a consistent output format too.

Ticket importer for allura export format - CONFIGTREE UPDATE

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

We should have a ticket importer that handles an upload of a JSON file created via Allura's own export functionality. Attachment URLs should be followed, so that they are imported as well.

Tracker API should include config & milestones & saved bins

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

The bulk export for a tracker includes config and milestones and saved bins. We should expose those through the regular API. The saved_bins includes extra stuff that should be removed (for both API and export). We don't need related_artifacts, discussion_thread, labels, discussion_thread_url. Those artifact-level fields aren't relevant here.

Forum API should check for posts' status

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

The new API in the ForgeDiscussion tool doesn't check for posts' statuses, so it will show 'pending' and 'spam' posts too, which aren't shown on the regular forum view. This may apply to discussion thread APIs in other tools too (e.g. ticket comments via API). It's an issue for individual threads URLs and also the API endpoint for a forum which lists the threads (a new thread that is just 1 post that is not "ok" status, shouldn't be listed, just like the web interface) Perhaps easiest would be to only show "ok" posts no matter what. Would be a bit nicer if a user with the proper rights could see the pending & spam posts too. That might be best with an additional flag in the URL to control whether to show those? Doesn't seem necessary to do that extra stuff at this point though.

API ticket updates should use web form logic

Chris Tsai — Fri, 26 Apr 2013 15:19:07 -0000

Currently, updating ticket details via the API behaves differently than if you update via the web form. Most notably, it "silently" updates. ie., it doesn't produce a comment logging the change, and it doesn't trigger an email notification. Wiki updates on the other hand will trigger an email just fine.

No attachment info for Allura API

Chris Tsai — Thu, 20 Aug 2015 22:07:55 -0000

Seems you can add an attachment via the API, but there's no info returned in the JSON about existing attachments. This would be particularly useful for projects using the API as a way to backup data.

Implement API endpoint for discussion tool

Chris Tsai — Thu, 20 Aug 2015 22:07:52 -0000

[forge:site-support:#2464] In particular, a user is requesting to make it easier to fix migrated posts that are improperly formatted due to markdown (he upgraded before we made the change to essentially disable markdown at upgrade time). But, I can see this as being something folks would want anyway.

Supplement oauth with simple api keys

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

Oauth is complicated for end-users, and simple API keys would be easier. A few features to think about: * security - builtin to oauth, not needed if traffic is on HTTPS * separate keys per app - a "simple" key approach should still allow multiple keys per account. Let users give them names, create more keys, and revoke keys. Are there any other features that oauth does provide?

API for posting to blog

Chris Tsai — Thu, 20 Aug 2015 22:07:57 -0000

I think this would be useful prerequisite for folks who would like to automate news posts with file release script.

"Building" Allura with setup.py

karsten — Thu, 20 Aug 2015 22:07:55 -0000

We are working on building a distro-specific package (RPM) of the Allura base install. We are making the assumption that distribution of Allura in this manner would be desirable, but haven't been able to test operation of the deployed package. When trying to run `python setup.py install` for the `Allura` app, I see the error: can't copy 'allura/templates/widgets/repo': doesn't exist or not a regular file We tracked this down to [this line](https://sourceforge.net/p/allura/git/ci/a8a2afd33f8c70336c72e212f9abb8d7d916b4e9/tree/Allura/setup.py#l67) We were able to fix this by changing a few of the lines: ::::diff - 'public/*/*', - 'templates/*/*'} + 'templates/**.html', + 'templates/**.py', + 'templates/**.xml', + 'templates/**.txt', + 'public/*/*/*/*/*'}

API to update ticket fields

Dave Brondsema — Tue, 07 Apr 2015 02:47:16 -0000

We should have a REST API to update ticket milestones and values for select boxes (status, component, etc)

Improve api documentation

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

https://sourceforge.net/p/forge/documentation/API%20-%20Beta/ David Burley the RW api docs should get updated to show how to do it using the raw HTTP requests that way folks can readily convert it to $language for those not python centric 11:57 Dave Brondsema good point, their is a lot of python there i'm not too familiar with oauth, i'm not sure how well examples work with raw HTTP, or if you really would always use a library 11:58 David Burley I'd probably link to that from a more general page to provide a specific python example Also, it'd be great if we could have this documentation both in the sf.net docs and the Allura docs. Maybe a brief entry for sf.net and linking over to Allura which has all the details?