Ticket search results

Pre-fill "private" using URL param

Chris Tsai — Mon, 24 Sep 2018 19:36:21 -0000

Something like https://sourceforge.net/p/forge/site-support/new/?private=true to pre-check the "private" checkbox would be especially nice on pages that ask for tickets for items like security vulnerabilities or anything else that might involve private data.

Only allow web based svn import if repo is empty

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

Had an incident this past week where a project accidentally wiped out their repository by trying to import while on the page for the wrong repo (and apparently provided incorrect data in the form as well). I think a good option to prevent this in the future would be to only allow repo imports over empty repos (might also prevent issues with trying to import onto a repo that's been borked via direct edits). Requiring the explicit extra step of deleting and recreating the repo should prevent unintentional overwriting.

Remove SF specific fields from metadata page

Chris Tsai — Tue, 03 Feb 2015 16:34:03 -0000

On /p/foo/admin/overview there are a lot of fields that are only useful in conjunction with sfpy. We should hide/remove those for non-SF Allura deployments. As far as I can tell, the following fields require sfpy: * Homepage * Full Description * Twitter * Facebook * Support page * Certain Project Statuses (deleted will make project publicly inaccessible, but if it's "moved" or "abandoned" we don't show that anywhere) Alternatively, we could figure out a way to display these somewhere without sfpy. We may want to remove/hide some, and add display capabilities for others.

Deleted tickets shouldn't be counted in search bins

Chris Tsai — Mon, 17 Aug 2015 21:49:03 -0000

Ticket counts in search bins includes deleted tickets, but I don't really think that they should.

site/neighborhood admin user subscription check

Chris Tsai — Fri, 12 Feb 2016 18:09:43 -0000

From a support perspective, it would be really, really great to be able to view a user's subscriptions, and ideally, also be able to unsubscribe when appropriate.

Default columns/views setting for tracker

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

I would love to be able to configure the default search used for a tickets landing page, and also the default columns shown on all ticket listings. In particular, for site-support, it doesn't really fit, so I don't use the "milestone" function at all, so it's just wasting screen real-estate, similarly, the assignee doesn't really matter, and I'd also love to show the "mod_time" in the default view.

site/neighborhood admins should be able to orphan projects

Chris Tsai — Sat, 07 Feb 2015 11:17:15 -0000

For support, we occasionally get requests to orphan projects, so site/neighborhood admins should be able to override the "no removing the last admin" control.

"Related" artifacts should indicate project/tool if referencing other project

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

As I link more support tickets to allura tickets, the "Related" section starts to get a bit confusing as there's no way (aside from checking the link URLS) to see which tickets are for the same ticketing system, and which go to a different project. Eg., I'm mentioning [forge:site-support:#1] and now the Related section will just say "Ticket: #1", and it's not obvious that it's not for this ticket tracker.

Revisions to /nf/admin/new_projects

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

* filter out deleted projects altogether; remove the column * checkbox is a tiny click target. Make clicking anywhere on the row check the checkbox. Except the links within the row. * In the Admins column, only show their username & link to /u/username (not all the User info like current) * CSS formatting in sftheme to make cells narrower so it all fits. * add ability to filter by date/date ranges (doesn't have to have a pretty UI, just simple textboxes ok). See how /nf/admin/task_manager does date range filtering via ObjectId. * remove the count() query since that is very slow with the `$ne` clause (that can't use an index). If the pagination doesn't work without knowing the total, change it to be a "next" button, which just passes a param that feeds into the date range filtering.

Autofill custom ticket fields by url param

Chris Tsai — Mon, 12 Jan 2015 13:31:38 -0000

Follow-up to [#4333]. Autofilling works for description, summary and labels, but not custom fields or other default fields. eg. https://sourceforge.net/p/allura/tickets/new/?_size=2&summary=foosdfds&description=bar&labels=bar,bling

"self" variable for ticket searches

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

I'd like to be able to set up a saved search that could return all the tickets reported by the user performing the search. Similar to how Trac uses `$USER` for that purpose (eg. ). Or some other way for users to (relatively) easily find the tickets they submitted.

Developer-only fields for tickets

Chris Tsai — Tue, 18 Nov 2014 10:40:29 -0000

It's often not desirable to allow users to change whatever fields they want (eg., re-opening closed tickets, or changing milestones), it would be nice to be able to mark fields in the field management as only developer-editable. It may also be useful to be able to set fields as only viewable by developers (eg. for internal tracking that may not be useful for regular users).

Subscribe another user to an artifact (global admin only)

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

At /nf/admin (only accessible by global admins) create a new left-menu item called 'Add Subscribers' which goes to a new page. On this page, there should be a form to enter a URL and a username. Take the URL and run it through URL dispatch to determine what artifact it goes with (e.g. ticket, wiki page). Note: if the URL dispatch is hard to do at all, we can use a different approach, like separate input boxes for neighborhood, project, tool mount point, ticket number. Then add the specified username as a subscriber to the artifact, if they aren't already. This should work just like when you subscribe yourself to a ticket, but for a different user.

Move tickets between ticket tools/projects

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

It would be useful to be able to move tickets between different ticket instances. Specific use cases for support would be: 1) moving confirmed bug reports to engr for further eval/processing. So we can maintain separate ticket queues without needing to manage duplicate tickets. 2) moving tickets that should have been logged to a project instead. I think both these cases could be covered by only allowing users with admin(?) permissions on both tickets instances to move tickets between them. *We should also consider auto-forwarding from the old ticket URL and not re-using the ticket number after a ticket has been moved.* Let's not do this yet. But we do need to figure out how to clean up old references to the old artifact path (e.g. solr and artifact references) *Another concern is how to handle custom fields/statuses that aren't shared by both tickets instances.* We should just drop those fields/values if they can't be converted. But we should put a comment on the ticket about the conversion and include the full URL of the prior ticket and also insert all the fields/values that couldn't be converted. The ticket artifact should stay the same, so that subscriptions and other stuff are preserved.

Autofill ticket fields by url param

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

There should be a way to pre-fill ticket fields, possibly using arguments in the URL like Trac does. We currently do this for reporting 404 and 500 errors to support Trac. Eg.

Add users to private tickets

Dave Brondsema — Tue, 10 Mar 2015 15:28:21 -0000

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.

Ticket create and edit should be separate permissions NEEDS MIGRATION

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

Currently, the `WRITE` permission controls both new ticket creation and editing existing tickets. These should be separated.

Better standard tool search results

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

Specifically the wiki search results should look better, but let's see how much improvement we can get through the generic search result template. E.g. https://sourceforge.net/p/allura/wiki/search/?q=faq A few suggestions * an option to only include primary artifacts (no comments) * artifact type (WikiPage) doesn't need to be shown in that case - best to stop including that in the title field when indexing? * exclude deleted pages * better relevance - e.g. a title match should be better than a body text match. I also think we are matching across too many fields in the first place. E.g. a search for "forgewiki" or "WikiPage" or the mount point shouldn't match the "internal" fields in the solr document. * show a preview of the content * change `

` for something better * add some metadata on the title line, like last modified date * if you choose to search history, the results links need "?version=N" * change sort order (relevance, date, etc) and direction * add search syntax help and examples (like we do for tickets) Here's a mockup of how https://sourceforge.net/p/allura/wiki/search/?q=faq could look: http://screencast.com/t/06dC4NjT60