Page MenuHomePhabricator
Create Task
Maniphest T6187

Allow query results to be exported to spreadsheet rendered in the browser
Closed, WontfixPublic
Actions

Description

Full disclosure: We are coming from trac which has a drop down with checkboxes. I probably first saw trac a decade ago so that makes sense to me but there are probably other ways to accomplish the same thing. http://trac.edgewall.org/query?priority=highest&priority=high&status=assigned&status=new&status=reopened&col=id&col=summary&col=priority&col=status&col=type&col=milestone&col=version&col=severity&col=resolution&order=priority

Use cases:

  • Eye-ball a count of something. For example, search for all of the project foo tickets and see 'a lot' are in status X but 'not very many' are in status Y.
  • Narrow search before bulk-edit. Search narrow it most of the way, but just click on a the last few tings to bulk edit. Doing that without opening up each ticket requires being able to see whatever field is relevant.

Related Objects
Search...

Event Timeline

cburroughs created this task.Sep 25 2014, 3:34 PM
cburroughs raised the priority of this task from to Needs Triage.
cburroughs updated the task description. (Show Details)
cburroughs added a project: Maniphest.
cburroughs added a subscriber: cburroughs.
chad added a subscriber: chad.Sep 25 2014, 4:37 PM

Not clear what you're suggesting specifically. With T418 we'll let you change what information is in task cards everywhere (which included search). Does that cover this or is there something specific to search you envision?

cburroughs added a comment.Sep 25 2014, 4:58 PM

Specific to search. If each ticket has 22 fields I don't want to display them all the time everywhere because that would be gross. But if I have searched and limited my results by field X, I would like to see how the values for Y break down. If there are 1000 results I don't want to have to click on all of them to do it. The trac ui does this by returning a row for each result and letting you select which columns are displayed with checkboxes. I like this but have no idea how it would fit into the card like search results that are used for display now.

chad added a comment.Sep 25 2014, 5:09 PM

There are many blockers to something like what Trac has, both in UI terms and in infrastructure. Anything built needs to be responsively designed (mobile, tablet, desktop) and work across all of Phabricator. This task essentially boils down to "Redesign Search", as it isn't particularly actionable without significant planning (Search is not currently on the roadmap).

chad added a comment.Sep 25 2014, 5:15 PM

At least, if there is something minor we can add to Search to improve your experience, it's not obvious to me what that is. Is there anything we can boil this down to?

chad renamed this task from Allow displaying more information in Maniphest search results to Provide better UI to manipulate information returned in large search results sets.Oct 7 2014, 6:22 PM
chad triaged this task as Normal priority.

I'm going to triage this into a general "Make search better on large results".

chad renamed this task from Provide better UI to manipulate information returned in large search results sets to Make ApplicationSearch better on large result sets.Oct 7 2014, 6:23 PM
chad edited projects, added ApplicationSearch; removed Maniphest.
cburroughs awarded a token.Oct 7 2014, 7:12 PM
cburroughs added a comment.Jan 13 2015, 5:40 PM

Its sounds like T6943 would cover most of this.

epriestley renamed this task from Make ApplicationSearch better on large result sets to Allow query results to be exported to spreadsheet rendered in the browser.Apr 23 2015, 7:22 PM
epriestley added a subscriber: epriestley.Apr 23 2015, 7:26 PM

We're vanishingly unlikely to redesign search results in the general case, and this request isn't compatible with responsive "object" list search results.

The desired output is basically a spreadsheet, which we do support. We can imagine a pathway between here and there like:

  • Lift spreadsheet export out of Maniphest and make it a generic capability of ApplicationSearch, so any result set in any application can be saved as a spreadsheet.
  • Make spreadsheet generation more generic: an export template class maps each object to a list of cells with style and formatting information.
  • Various renderers can take those cells and turn them into a document.
    • The default "Excel" renderer would turn them into a ".xls" document.
    • An alternate renderer could turn them into an unformatted ".csv" document.
    • A third renderer could turn them into an HTML table.
  • Then, we could give you an option to pipe the results through the export pipeline into an HTML table instead of through the standard rendering pipeline into an object list.

This is probably a fairly long way away.

epriestley added a subtask: T5307: UX for taking actions with search results.Apr 23 2015, 7:27 PM

T5307 discusses finding some way to fit "Export to spreadsheet.." -- and various other options -- into the UI in the general case.

epriestley lowered the priority of this task from Normal to Wishlist.Apr 23 2015, 7:27 PM
chad closed subtask T5307: UX for taking actions with search results as Resolved.Mar 21 2017, 2:13 AM
epriestley closed this task as Wontfix.Jan 31 2018, 12:38 AM
epriestley claimed this task.

After T13049 this is relatively within reach, but we haven't seen other requests for it so I don't currently plan to pursue it.

In T13025, the bulk editor got support for refining the result set after you start the edit operation. You don't get a whole table to work with, but this should at least somewhat address case (2).

This broader request could be supported by implementing an "HTML" or "Spreadpheet" export format alongside the existing CSV, JSON, Text and Excel formats that just dumped out a bunch of HTML <table /> tags. The export pipeline would probably need a couple of tweaks since we want to show the data in the browser instead of downloading it, but this isn't insurmountable. But you can also just dump the list into Excel and do pretty much the same thing.

I'm open to pursuing this eventually if more use cases arise or it ends up adjacent to other things, interest/value just seems low and complexity relatively high.

Phabricator · Built by Phacility