<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Ticket search results</title><link>https://forge-allura.apache.org/p/allura/tickets/</link><description>You searched for labels:"hostedapps"</description><language>en</language><lastBuildDate>Thu, 20 Aug 2015 22:07:57 -0000</lastBuildDate><item><title>No documentation on importing from MediaWiki into Allura Wiki</title><link>https://forge-allura.apache.org/p/allura/tickets/5190/</link><description>*Originally created by:* tfry

I see work has been done to support migrating from MediaWiki (hosted app) to the Wiki in Alllura: [#4186], [#4660]. But I can't seem to find the least bit of documentation on how to actually use this.

I'm perfectly willing to contribute to such documentation, but I'd really need some basic pointers on where to start.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Anonymous</dc:creator><pubDate>Thu, 20 Aug 2015 22:07:54 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/5190/</guid></item><item><title>Speedups needed for /nf/admin/add_subscribers</title><link>https://forge-allura.apache.org/p/allura/tickets/4567/</link><description>Followup to [#4449].  The mongo queries on /nf/admin/add_subscribers take too long to run in production (over 30 seconds).

My recommendation for a speedup would be this:  after determining the tool/app from the URL, get the package name (e.g. for tickets, the package is "forgetracker").  Then when checking the Artifact models, only do artifacts whose packages starts with "forgetracker".  That should limit the number of queries quite a bit.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Thu, 20 Aug 2015 22:07:55 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/4567/</guid></item><item><title>Add voting to tickets</title><link>https://forge-allura.apache.org/p/allura/tickets/4481/</link><description>We want to provide functionality so we can adequately replace the Ideatorrent hosted app: https://sourceforge.net/apps/ideatorrent/sourceforge/

See also discussion at [79bed0f2]. 

* create a `VotableArtifact` class (will be later used as a mixin with other artifact classes).  It should have `Field`s for votes_up (int), votes_down (int), votes_up_users (list), votes_down_users (list), and methods `vote_up` and `vote_down` which require a User as an argument.  You can only vote once, so changing your vote would remove it from the other list.
* In ForgeTracker, make `Ticket` extend `VotableArtifact` also.  We are not 100% sure how ming handles Fields from mixins, but it should work automatically.  It does for single inheritance.
* Include the votes_up_i and votes_down_i in the `Ticket.index()` method.  Also add `votes_total_i` which is `up` - `down`.  (The _i suffix makes them an int in solr schema). Document them in the tracker's search help text.
* Make sure every time a vote occurs, the object is saved to solr.  This can happen in either VotableArtifact or the Ticket class, whichever makes most sense.
* Add a ForgeTracker admin option so that project admins can enable/disable voting on tickets.
* If that is enabled for a tracker, any visitor with 'post' permission on a ticket should be able to click to vote up or down.  However, a visitor must also be logged in (i.e. anonymous with 'post' access cannot vote).
* The UI should look like http://screencast.com/t/T2rvuefPa6F  See the notes for the HTML and CSS.  If the user has already voted, the current vote should show up in red.  (The appearance may end up somewhat different from the screenshot, since that is using our non-OSS theme)
* Use AJAX to POST to a URL like /p/allura/tickets/1234/vote.  Our CSRF protection will automatically be added to any html form (a _session_id hidden field), but you should make sure it is submitted with ajax too.
* If voting is enabled for a tracker, show the `votes_total` field as a column in the ticket listing pages.  You should be able to click on it to sort by it.
</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Thu, 20 Aug 2015 22:07:56 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/4481/</guid></item><item><title>Add users to private tickets</title><link>https://forge-allura.apache.org/p/allura/tickets/4320/</link><description>After [#3892] is done, there should be a UI to add another user to have permission to read a private ticket.  Someone with 'edit' permission on a ticket should be able to add the additional users.

I believe private tickets are implement with an artifact-level ACL, not merely a boolean flag, so the backend support should be correct.  However, we should double check that the ACL is used in all relevant permission checks, so it works fully.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Tue, 10 Mar 2015 15:28:21 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/4320/</guid></item><item><title>Ticket create and edit should be separate permissions NEEDS MIGRATION</title><link>https://forge-allura.apache.org/p/allura/tickets/3892/</link><description>Currently, the `WRITE` permission controls both new ticket creation and editing existing tickets. These should be separated.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Chris Tsai</dc:creator><pubDate>Thu, 20 Aug 2015 22:07:57 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/3892/</guid></item></channel></rss>