Page MenuHomePhabricator

Export "date" and "remarkup" custom fields to Excel + "zip" extension check
ClosedPublic

Authored by epriestley on Jul 17 2019, 10:57 PM.
Tags
None
Referenced Files
F14861374: D20658.diff
Fri, Feb 7, 9:24 AM
Unknown Object (File)
Sun, Feb 2, 3:26 AM
Unknown Object (File)
Sat, Jan 25, 4:35 PM
Unknown Object (File)
Sat, Jan 25, 4:35 PM
Unknown Object (File)
Sat, Jan 25, 4:35 PM
Unknown Object (File)
Thu, Jan 23, 9:32 PM
Unknown Object (File)
Wed, Jan 22, 5:17 PM
Unknown Object (File)
Tue, Jan 21, 11:50 AM
Subscribers
None

Details

Summary

Fixes T13342. This does a few different things, although all of them seem small enough that I didn't bother splitting it up:

  • Support export of "remarkup" custom fields as text. There's some argument here to export them in some kind of structure if the target is JSON, but it's hard for me to really imagine we'll live in a world some day where we really regret just exporting them as text.
  • Support export of "date" custom fields as dates. This is easy except that I added null support.
  • If you built PHP from source without "--enable-zip", as I did, you can hit the TODO in Excel exports about "ZipArchive". Since I had a reproduction case, test for "ZipArchive" and give the user a better error if it's missing.
  • Add a setup check for the "zip" extension to try to avoid getting there in the first place. This is normally part of PHP so I believe users generally won't hit it, I just hit it because I built from source. See also T13232.
Test Plan
  • Added a custom "date" field. On tasks A and B, set it to null and some non-null value. Exported both tasks to Excel/JSON/text, saw null and a date, respectively.
  • Added a custom "remarkup" field, exported some values, saw the values in Excel.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable