<?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 assigned_to:"jetmind"</description><language>en</language><lastBuildDate>Wed, 27 Jan 2016 20:43:32 -0000</lastBuildDate><item><title>API for current site notification</title><link>https://forge-allura.apache.org/p/allura/tickets/8044/</link><description>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.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Wed, 27 Jan 2016 17:43:01 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/8044/</guid></item><item><title>Better handing of tmp dirs during merge</title><link>https://forge-allura.apache.org/p/allura/tickets/8042/</link><description>Doing a one-click merge of a very large repo can potentially cause problems if the working dir is bigger than the tmp dir mount supports.

* `def merge` can use a try/finally so that `shutil.rmtree` always runs even if the clone fails (e.g. out of disk space)
* see if its possible to a shared clone (see also `_shared_clone`) so the object files don't have to get copied, reducing disk usage and execution time.

It'd be nice if we could set a max size limit and check that in `can_merge` or `merge_allowed` but it doesn't seem to be a way to check the size of a working copy ahead of time.  There is `git count-objects -vH` but that's just the repo size, not the working copy.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Wed, 27 Jan 2016 20:43:32 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/8042/</guid></item><item><title>Change "Label" admin option to "Rename"</title><link>https://forge-allura.apache.org/p/allura/tickets/8037/</link><description>I think the "Label" admin option would be easier to understand if it was "Rename".

This may show up in several places in the UI, and we should update all of them.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Mon, 25 Jan 2016 15:34:14 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/8037/</guid></item><item><title>Site notification admin interface</title><link>https://forge-allura.apache.org/p/allura/tickets/8024/</link><description>The site admin pages should have a way to manage site notifications.  Also, make sure to update the Site Notification part of the docs.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Mon, 11 Jan 2016 15:26:50 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/8024/</guid></item><item><title>More flexibility to the site-wide notifications</title><link>https://forge-allura.apache.org/p/allura/tickets/8023/</link><description>Site notifications would be more useful if they had options to control who they were shown to and on what pages.  For the user, some obvious options are show to everyone, or show to project devs/admins.  I can't think of others right now.  For the pages, tool type(s) could be a useful selection.  But all pages are a tool (plus I'd like this to be able to work with external code that can integrate with Allura) so a url regex would be a good option too.  That'd cover lots of possibilities (specific neighborhood, specific project, auth pages, create project page, etc).</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Mon, 11 Jan 2016 15:26:44 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/8023/</guid></item><item><title>Easy way to view all posts from a certain user, and flag as spam</title><link>https://forge-allura.apache.org/p/allura/tickets/8020/</link><description>The moderation page should have a field to filter by a username - then it will be easier to get a list of all the posts by a user in that forum, and select-all to mark as spam.

Also, when in the regular view of a post and you click "Spam" and the message goes away, we should show a little message box in its place that explains what just happened, and a link to go over to the moderation view and see all posts by the user (so project admins know that is possible and have an easy way to get there).  An undo link there would be very nice too.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Wed, 27 Jan 2016 17:17:46 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/8020/</guid></item><item><title>Dialog 'cancel' link in wrong place</title><link>https://forge-allura.apache.org/p/allura/tickets/8016/</link><description>On dialog boxes like new tool installation, and "Checkout URL" repo options, the 'cancel' link is in the wrong place.  Perhaps related to recent icon changes including that "close" link in upper right of those dialogs.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Mon, 30 Nov 2015 15:35:24 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/8016/</guid></item><item><title>Bug: removed upsert() method needed by TracWikiImporter</title><link>https://forge-allura.apache.org/p/allura/tickets/8014/</link><description>We removed upsert() in [f33baf] but it is actually used.  We should bring it back with a `user` param, or update TracWikiImporter to not need it.

    Traceback (most recent call last):
      File "/var/local/allura/ForgeImporters/forgeimporters/base.py", line 131, in import_tool
        mount_point=mount_point, mount_label=mount_label, **kw)
      File "/var/local/env-allura/lib/python2.7/site-packages/TracWikiImporter-0.4.2-py2.7.egg/tracwikiimporter/importer.py", line 94, in import_tool
        options.token = self.get_token(user)
      File "/var/local/env-allura/lib/python2.7/site-packages/TracWikiImporter-0.4.2-py2.7.egg/tracwikiimporter/importer.py", line 116, in get_token
        consumer_token = OAuthConsumerToken.upsert(self.classname)
    AttributeError: type object 'OAuthConsumerToken' has no attribute 'upsert'</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Mon, 16 Nov 2015 16:09:46 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/8014/</guid></item><item><title>Markdown editor does not load when url hash contains slashes</title><link>https://forge-allura.apache.org/p/allura/tickets/8010/</link><description>Compare https://forge-allura.apache.org/p/allura/tickets/7924/#d1d2/ed24/f3ed and https://forge-allura.apache.org/p/allura/tickets/7924/#d1d2 for example

In the first case markdown editor does not load and console has the following errors:

~~~~
Uncaught Error: Syntax error, unrecognized expression: #d1d2\/ed24/f3ed.title-pane
(index):6200 Uncaught TypeError: $(...).tagsInput is not a function
(index):6334 Uncaught TypeError: Cannot read property 'CodeMirror' of undefined
~~~~

in the second case editor is loading just fine

Chrome Version 46.0.2490.71 (64-bit), Ubuntu
</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Igor Bondarenko</dc:creator><pubDate>Mon, 11 Jan 2016 15:26:38 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/8010/</guid></item><item><title>Bugs in attachments to comments</title><link>https://forge-allura.apache.org/p/allura/tickets/8003/</link><description>Editing a comment to modify its attachments has some bugs, compared to what you can do for top-level artifact attachments.

* no way to delete an attachment
* uploading with the same name duplicates the file, rather than replace it (see [#4350] which could be considered a feature)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Mon, 11 Jan 2016 15:26:34 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/8003/</guid></item><item><title>Admin page to really delete projects</title><link>https://forge-allura.apache.org/p/allura/tickets/7999/</link><description>Admins should be able to really delete projects, not just soft-delete.  (Here's all the things we can do, possibly break out into separate tickets)

* create admin page with a textarea in which project names or urls can be entered, whitespace separated.  
* `ProjectRegistrationProvider` should have a method to parse the (nbhd,project) out of each URL, so that custom sites urls can be parsed specially if needed.
* to actually do the removal, SF can contribute our `forge-classic/scripts/purge-project` logic.  Just need to do a little refactoring:
    * remove `find_project_by_unix_name` usage, it should work with a (nbhd,project) or such
    * probably good to make it a `ScriptTask` so it can be run that way too
    * forge-classic script should call the new script
* fire an event so other custom hooks can do things upon project deletion if needed
* /nf/admin/new_projects already builds a list of project names at the bottom of the page as you click the checkboxes.  Enhance that list of names to link over to to the project deletion form.
* include a text box for "reason".  Log it to disk, and include in the event parameters.
* have a checkbox for "Disable all project members".  It should disable all users that are admins or devs of the project.  And add a user audit log comment, noting the related project and the "reason" given.
* document it in administration.rst</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Mon, 30 Nov 2015 15:35:11 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/7999/</guid></item><item><title>Adding attachment to wiki loses your text changes</title><link>https://forge-allura.apache.org/p/allura/tickets/7998/</link><description>When editing a wiki page and adding or removing an attachment, any changes you may have made to the wiki text get lost.

I'd suggest we make the add &amp; delete attachments into ajax calls.  (Another option would be submit the wiki text form too and controller would handle both types of changes at once).  Ajax would be a nice direction towards someday allowing drag/drop of images into a markdown editor and auto-attach and insert `[[img src=...]]` for you.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Mon, 11 Jan 2016 15:26:30 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/7998/</guid></item><item><title>image attachments visible on posts (replies) awaiting moderation</title><link>https://forge-allura.apache.org/p/allura/tickets/7997/</link><description>I have a thread with a reply sitting in it awaiting moderation. There are image attachments, and I can see the image attachments. I mean, even as a logged-out user, not being the moderator. It literally says "post awaiting moderation. attachments:"

Attachments shouldn't be visible on posts awaiting moderation.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">zeromus</dc:creator><pubDate>Mon, 30 Nov 2015 15:35:06 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/7997/</guid></item><item><title>Standardize fenced blocks in markdown</title><link>https://forge-allura.apache.org/p/allura/tickets/7987/</link><description>Switch from our custom `FencedCodeProcessor` to the standard extension https://pythonhosted.org/Markdown/extensions/fenced_code_blocks.html so that we can support \`\`\` style, and so that blank lines are not needed before and after the `~~~~` blocks.  This will get us more closely aligned with the CommonMark standard, and the syntax highlighting of the markdown editor, and the 

However, the format for denoting the language inside the block is different there than the [CodeHilite](https://pythonhosted.org/Markdown/extensions/code_hilite.html) extension which we are already using (and our current `~~~~` uses as well since it simply makes an indented block).  So we'll have to figure out how to reconcile that.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Mon, 11 Jan 2016 15:26:25 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/7987/</guid></item><item><title>Activity page fixes</title><link>https://forge-allura.apache.org/p/allura/tickets/7978/</link><description>* need `@with_trailing_slash` for activity tool, otherwise things don't load right and you can't "follow"
* it's not clear what following does.  A few simple things to make the unified activity timeline page /u/&lt;your-own-username&gt;/activity easier to understand would help that.
    * We should add more links to that page  E.g. from every activity page, from your profile or settings
    * And adjust the title of that page so its clear</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Mon, 14 Dec 2015 16:10:51 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/7978/</guid></item><item><title>Better binary file detection</title><link>https://forge-allura.apache.org/p/allura/tickets/7962/</link><description>Improve our binary/text file detection.

[here is an example](https://sourceforge.net/p/planetexpress/git/ci/ba49bf3d9b3185ea2b0dc5cb6f7a3f8a6781f0c4/) of a jpg with a ".d" extention that made it through the **has_html_view** function(  `allura.model.repository.Blob#has_html_view`)


Performance should be a primary consideration because of the large number of calls on bigger commits.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Heith Seewald</dc:creator><pubDate>Thu, 22 Oct 2015 15:17:59 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/7962/</guid></item><item><title>Cursor position often wrong in new markdown editor</title><link>https://forge-allura.apache.org/p/allura/tickets/7948/</link><description>When editing text in the new markdown editor, the cursor can be off by a line (or few?).  This seems to happen  reliably, but exact cause is not narrowed down yet.  Seems to only be when editing existing content, not when creating new content (even pasting the exact same text).  I think it has to do with the initial height of the input area being tall.  Sometimes I can get the cursor to work properly again if I add or delete enough rows to make the textarea resize some amount.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Mon, 24 Aug 2015 14:29:42 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/7948/</guid></item><item><title>Error setting channel in Chat's options</title><link>https://forge-allura.apache.org/p/allura/tickets/7946/</link><description>1. Go to Admin -&gt; Tool
2. Find "Chat" tool and click "Options"
3. Enter something in the "channel" field
4. Click "Save"

&amp;nbsp;

~~~~~
URL: http://localhost:8080/p/test/admin/chat/configure
File '/usr/local/lib/python2.7/dist-packages/weberror/evalexception.py', line 438 in respond
  return_iter = list(app_iter)
File '/usr/local/lib/python2.7/dist-packages/paste/registry.py', line 409 in streaming_iter
  for item in self.application(environ, start_response):
File '/usr/local/lib/python2.7/dist-packages/ming/odm/middleware.py', line 20 in __call__
  result = self.app(environ, start_response)
File '/allura/Allura/allura/lib/custom_middleware.py', line 60 in __call__
  return self.app(environ, start_response)
File '/usr/local/lib/python2.7/dist-packages/ew/middleware.py', line 65 in __call__
  result = self.app(environ, start_response)
File '/allura/Allura/allura/lib/custom_middleware.py', line 263 in __call__
  return resp(environ, start_response)
File '/allura/Allura/allura/config/middleware.py', line 201 in AlluraGlobalsMiddleware
  return app(environ, start_response)
File '/allura/Allura/allura/lib/custom_middleware.py', line 217 in __call__
  return self._app(environ, session_start_response)
File '/usr/local/lib/python2.7/dist-packages/timermiddleware/__init__.py', line 196 in __call__
  resp = req.get_response(self.app)
File '/usr/local/lib/python2.7/dist-packages/webob/request.py', line 1053 in get_response
  application, catch_exc_info=False)
File '/usr/local/lib/python2.7/dist-packages/webob/request.py', line 1022 in call_application
  app_iter = application(self.environ, start_response)
File '/allura/Allura/allura/lib/custom_middleware.py', line 156 in __call__
  self.app, environ, catch_exc_info=True)
File '/usr/local/lib/python2.7/dist-packages/pylons/util.py', line 48 in call_wsgi_application
  app_iter = application(environ, start_response)
File '/allura/Allura/allura/lib/custom_middleware.py', line 391 in __call__
  return self.app(environ, remember_login_start_response)
File '/usr/local/lib/python2.7/dist-packages/beaker/middleware.py', line 155 in __call__
  return self.wrap_app(environ, session_start_response)
File '/usr/local/lib/python2.7/dist-packages/routes/middleware.py', line 131 in __call__
  response = self.app(environ, start_response)
File '/usr/local/lib/python2.7/dist-packages/pylons/wsgiapp.py', line 107 in __call__
  response = self.dispatch(controller, environ, start_response)
File '/usr/local/lib/python2.7/dist-packages/pylons/wsgiapp.py', line 312 in dispatch
  return controller(environ, start_response)
File '/allura/Allura/allura/lib/base.py', line 49 in __call__
  environ, start_response)
File '/usr/local/lib/python2.7/dist-packages/pylons/controllers/core.py', line 211 in __call__
  response = self._dispatch_call()
File '/usr/local/lib/python2.7/dist-packages/pylons/controllers/core.py', line 162 in _dispatch_call
  response = self._inspect_call(func)
File '/usr/local/lib/python2.7/dist-packages/pylons/controllers/core.py', line 105 in _inspect_call
  result = self._perform_call(func, args)
File '/usr/local/lib/python2.7/dist-packages/tg/controllers/dispatcher.py', line 258 in _perform_call
  r = self._call(func, params, remainder=remainder)
File '/usr/local/lib/python2.7/dist-packages/tg/controllers/decoratedcontroller.py', line 120 in _call
  output = controller_callable(*remainder, **dict(params))
TypeError: configure() got an unexpected keyword argument '_session_id'
~~~~~</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Igor Bondarenko</dc:creator><pubDate>Mon, 28 Sep 2015 18:49:13 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/7946/</guid></item><item><title>Limit the "_discuss" results from the tickets api.</title><link>https://forge-allura.apache.org/p/allura/tickets/7943/</link><description>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.
</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Heith Seewald</dc:creator><pubDate>Mon, 05 Oct 2015 13:59:37 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/7943/</guid></item><item><title>Bug: viewing a thread updates project mod_date</title><link>https://forge-allura.apache.org/p/allura/tickets/7930/</link><description>Viewing a thread updates the `view_count` field, which causes the project `mod_date` to be updated, but it shouldn't.  We already have some special handling for `view_count` fields but we need more:

https://forge-allura.apache.org/p/allura/git/ci/ca2233e3c25a177d0ef651f49fed1ead67212035/

https://forge-allura.apache.org/p/allura/git/ci/af4d036acd7a63ccde241be69945cc5a66155e4b/</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Mon, 10 Aug 2015 14:28:09 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/7930/</guid></item><item><title>Enable CORS access to rest APIs</title><link>https://forge-allura.apache.org/p/allura/tickets/7927/</link><description>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.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Mon, 27 Jul 2015 14:35:17 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/7927/</guid></item><item><title>Set up 'pelican' for publishing our website</title><link>https://forge-allura.apache.org/p/allura/tickets/7926/</link><description>If we want to create additional web pages (e.g. for news, feature announcements, howtos) with the same theme as the homepage then we should set up some light-weight system for publishing them easily.  http://blog.getpelican.com/ might be a good option, since it is python-based.

Repo is at https://svn.apache.org/repos/asf/allura/site/

Also consider switching our web repo from SVN to https://blogs.apache.org/infra/entry/git_based_websites_available</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Dave Brondsema</dc:creator><pubDate>Mon, 27 Jul 2015 14:35:22 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/7926/</guid></item><item><title>Update icons</title><link>https://forge-allura.apache.org/p/allura/tickets/7924/</link><description>Our icons should be updated and support hidpi screens.  [Font awesome](http://fortawesome.github.io/Font-Awesome/) might be a good choice or possibly [fontello](http://fontello.com/).

Licenses need to be taken into consideration and included in the appropriate places.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Heith Seewald</dc:creator><pubDate>Mon, 02 Nov 2015 15:09:18 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/7924/</guid></item><item><title>Left sidebar should show appropriate links when viewing tool options</title><link>https://forge-allura.apache.org/p/allura/tickets/7923/</link><description>When you're on an admin page for a tool, show the tool sidebar instead of the admin.


One option would be to replace the default `AdminController` all together and incorporate the admin options directly in the app's `RootController`. This might be more work then extending/replacing the app's side_bar menu -- but it also may be a cleaner solution.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Heith Seewald</dc:creator><pubDate>Mon, 24 Aug 2015 14:30:03 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/7923/</guid></item><item><title>Add "admin" section to the left sidebar</title><link>https://forge-allura.apache.org/p/allura/tickets/7922/</link><description>Create a collapsible admin section on the left sidebar of each tool.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Heith Seewald</dc:creator><pubDate>Mon, 24 Aug 2015 14:30:09 -0000</pubDate><guid>https://forge-allura.apache.org/p/allura/tickets/7922/</guid></item></channel></rss>