1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-05 05:02:44 +01:00
Commit graph

14101 commits

Author SHA1 Message Date
epriestley
704afea281 Add PackagesPackage
Summary:
Ref T8116. A package has:

  - a publisher (like "Phacility"), from the previous revision;
  - a name (like "Arcanist");
  - a package key (like "arcanist").

The package key is immutable, like the publisher key.

This gives a package a full key like "phacility/arcanist".

Policy stuff:

  - You must be able to view a publisher to view a package (currently, everyone can always see all publishers).
  - You must be able to edit a publisher to create a new package inside it.
  - Packages have separate view/edit permissions.

This still does nothing interesting.

Test Plan: {F1731663}

Reviewers: chad

Reviewed By: chad

Subscribers: eadler

Maniphest Tasks: T8116

Differential Revision: https://secure.phabricator.com/D16315
2016-07-27 12:22:57 -07:00
epriestley
9160da1afb Add a Packages application and PackagePublisher
Summary:
Ref T8116. Partially scavenged from D14152. This roughs in a new Packages application for Arcanist extensions and third-party applications, and adds a "Publisher" object.

A "Publisher" represents an individual or entity who is publishing a package, like "Phacility". It's explicitly //not// necessarily the original author -- just the primary entity vouching for the safety of the code.

A publisher just has a name and a unique key for now. For example, Phacility might have "Phacility" and "phacility", respectively.

Unique keys are immutable, e.g., the package "phacility/arcanist" will always be exactly the same package by exactly the same publisher.

Test Plan: {F1731621}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T8116

Differential Revision: https://secure.phabricator.com/D16314
2016-07-27 12:21:57 -07:00
epriestley
eab74a9d7c Provide better headers and crumbs for Calendar result views
Summary:
Ref T11326. This isn't perfect, but should be a little easier to use and less weird/confusing.

Generally, provide a "Query > Month > Day" crumb on day views, and a "Wed, July 3" header.

Generally, provide a "Query > Month" crumb on month views, and a "July 2019" header.

Also try to fix a bit of padding/spacing on the day view.

Test Plan: {F1739128}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16338
2016-07-27 09:44:56 -07:00
epriestley
ef6c689e87 When a Calendar day has too many events, show a "More..." link
Summary: Fixes T8361.

Test Plan: {F1739073}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T8361

Differential Revision: https://secure.phabricator.com/D16337
2016-07-27 09:44:35 -07:00
epriestley
89f6764e1b Give Calendar days from adjacent months a background color hint
Summary:
Ref T11326. When viewing "February", add a class to dates in January and March to let them be styled a little differently as a UI hint.

For now, I've given them a grey background. (Calendar.app changes the date number color instead.)

Test Plan: {F1738990}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16336
2016-07-27 09:38:18 -07:00
epriestley
ba00022730 Remove extra margins on Calendar month view
Summary:
Ref T11326. This doesn't go quite as far as the mock in T11326#185932, but gets rid of the easy margins.

Also cleans up some of the border rules so they're simpler and more consistent (no weird ragged edges on the far right).

Test Plan: {F1738951}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16335
2016-07-27 09:36:40 -07:00
epriestley
aee9d88c17 Give the Calendar month view a nice hover effect
Summary:
Ref T11326. Currently, we link Calendar days using hidden DOM nodes.

This is nice because it's simple, and right-clicking a day works properly. However, it's a bit ugly/unintuitive, messy, and unclear. It's especially messy because days are really two different rows, one for events and one for day/week numbers.

Instead, use JS to highlight day cells. You can still right-click by clicking the actual day number, which seems like a reasonable compromise.

Test Plan: {F1738941}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16334
2016-07-27 09:36:07 -07:00
epriestley
cd8eccde8a Cruncy legumes.
Auditors: chad
2016-07-27 05:07:38 -07:00
epriestley
e5256bd815 Hide time controls when editing all-day Calendar events
Summary:
Ref T11326. When an event is all-day, hide the time controls for the start/end dates. These aren't used and aren't helpful/useful.

This got a little more complicated than it used to be because EditEngine forms may have only some of these controls present.

Test Plan: Edited an all-day event; edited a normal event; swapped an event between normal and all-day.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16327
2016-07-27 05:01:19 -07:00
Chad Little
c6ba4272d7 Clean up mobile spacing on info views in a column
Summary: When we have an info view in a column, the css isn't specific enough to override the core info-view css.

Test Plan: Review an importing repository, see info view properly spaced.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D16331
2016-07-26 13:04:04 -07:00
Chad Little
f5e801f358 Clean up spacing on mobile form instructions
Summary: This padding is a little off / custom. Normalizes it to the form on mobile.

Test Plan: Review some settings forms, save form changes.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D16330
2016-07-26 12:35:18 -07:00
Chad Little
cfb6d5a70c Clean up mobile crumb padding
Summary: These feel mis-aligned now. Equalizes paddding left and right.

Test Plan: Review a task create, workboards.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D16328
2016-07-26 12:22:43 -07:00
Chad Little
6a5cfe3b02 Roomier forms on mobile
Summary: Mobile forms are super tight, this opens them up a little bit.

Test Plan: Review editing a document, task, mobile, tablet.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D16329
2016-07-26 12:21:50 -07:00
epriestley
637b58c7c8 Correct an issue with epoch timestamps in Conduit
Summary:
Fixes T11375. Some validation code was mishandling raw epoch timestamps.

For numeric values larger than 29999999 (e.g., 2999-12-25, christmas 2999), assume the value is a timestamp.

Test Plan: Used `maniphest.search` to query for `modifiedStart`, got a better result set and saw the `dateModified` constraint in the query.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11375

Differential Revision: https://secure.phabricator.com/D16326
2016-07-26 11:02:46 -07:00
Daniel Stone
29d6e5fd4b Use numeric input control for TOTP factor entry
Summary:
Finishes fixing T11365. rP28199bcb48 added the new numeric entry
control and used it for TOTP setup, but missed the case of entering
a factor when TOTP was already set up.

Test Plan:
Observe behaviour of TOTP setup and subsequent factor entry
in iOS browser, make sure they're consistent.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: epriestley

Maniphest Tasks: T11365

Differential Revision: https://secure.phabricator.com/D16325
2016-07-26 04:47:02 -07:00
epriestley
020df6f5cb Add a numeric input control for TOTP codes
Summary:
Fixes T11365. I tested these variants:

  - `<input type="number" />`
  - `<input type="text" pattern="\d*" />`

Of these, this one (using `pattern`) appears to have the best behavior: it shows the correct keyboard on iOS mobile and does nothing on desktops.

Using `type="number"` causes unwanted sub-controls to appear in desktop Safari, and a numbers + symbols keyboard to appear on iOS (presumably so users can type "." and "-" and maybe ",").

Test Plan: Tested variants in desktop browsers and iOS simulator, see here and T11365 for discussion.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11365

Differential Revision: https://secure.phabricator.com/D16323
2016-07-23 21:13:47 -07:00
Aviv Eyal
b6bf0f6a3b Re-implement calendar.invite transactions
Summary:
Fix T11339.
Now, old and new are both simple lists of phids, and the rendering should make sense.

Test Plan: Viewed existing transaction with all 3 states.

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: Korvin

Maniphest Tasks: T11339

Differential Revision: https://secure.phabricator.com/D16311
2016-07-22 18:03:28 +00:00
epriestley
fc950140b4 Blanket reject request which may have been poisoned by a "Proxy" header to mitigate the httpoxy vulnerability
Summary:
See accompanying discussion in T11359.

As far as I can tell we aren't vulnerable, but subprocesses could be (now, or in the future). Reject any request which may have a `Proxy:` header.

This will also do a false-positive reject if `HTTP_PROXY` is defined in the environment, but this is likely a misconfiguration (cURL does not read it). I'll provide guidance on this.

Test Plan:
  - Made requests using `curl -H Proxy:...`, got rejected.
  - Made normal requests, got normal pages.

Reviewers: chad, avivey

Reviewed By: avivey

Differential Revision: https://secure.phabricator.com/D16318
2016-07-21 20:18:06 -07:00
Aviv Eyal
68904d941c bin/storage shell: force TCP
Summary:
`mysql` has the magic feature of ignoring port arguments and using the socket when connecting to localhost.

This flag makes it not do that.

Test Plan: `./bin/storage shell`, execute `status`, see `Connection: localhost via TCP/IP`.

Reviewers: joshuaspence, #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D16317
2016-07-21 23:42:27 +00:00
epriestley
c27ba19da3 Raise human-readable error messages for overlong Phame blog titles and subtitles
Summary:
Fixes T11358. Entering a too-long title/subtitle currently raises an unfriendly (database-level) error.

Raise a friendlier error.

Test Plan: {F1731533}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11358

Differential Revision: https://secure.phabricator.com/D16313
2016-07-21 09:48:06 -07:00
epriestley
56bd762dd3 Allow file comments to be edited
Summary:
Fixes T10750. Files have some outdated cache/key code which prevents recording an edit history on file comments.

Remove this ancient cruft.

(Users must `bin/storage adjust` after upgrading to this patch to reap the benefits.)

Test Plan:
  - Ran `bin/storage adjust`.
  - Edited a comment in Files.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10750

Differential Revision: https://secure.phabricator.com/D16312
2016-07-18 16:17:43 -07:00
epriestley
959337ec62 Add crumbs to Calendar events to return to the month/day view
Summary: Ref T11326. This makes it a little easier to jump back up to check out your day.

Test Plan: {F1725575}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16309
2016-07-15 14:24:55 -07:00
epriestley
4859a33739 Make Calendar day view a little more consistent
Summary: Ref T11326. This just cleans things up a little and removes some of the obvious layout/CSS issues.

Test Plan:
- Viewed day view before/after. Also viewed profile panel.

Before:

{F1725547}

After:

{F1725548}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16308
2016-07-15 14:24:29 -07:00
Sbastien Santoro
7e49479ab0 discouarges → discourages
Test Plan: Read again the sentence.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D16307
2016-07-15 21:06:47 +00:00
epriestley
b6c3d184d2 Make Calendar month view events render a little more consistently
Summary:
Ref T11326. This just inches things forward a little bit:

  - Make it easier to see current day.
  - Line-through cancelled events.
  - Don't colorize the whole event title, just use an Attending/Invited/Custom icon.
  - Slightly subtler treatment for all-day events.

Test Plan: See screenshot in T11326.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16306
2016-07-15 13:24:54 -07:00
epriestley
e2b6912b9d Store "All Day" events in a way that is compatible with EditEngine
Summary:
Ref T11326. Normally, events occur at a specific epoch, independent of the viewer. For example, if we're having a meeting in 35 hours, every user who looks at the event will see that it starts 35 hours from now.

But when an event is "All Day", the start time and end time depend on the //viewer//. A day like "Christmas" does not start at the same time for everyone: it starts sooner if you're in a more-eastern timezone. Baiscally, an event on "July 15th" starts whenever "July 15th" starts for whoever is looking at it.

Previously, we stored these events by using the western-most and eastern-most timezones as the start and end times (the earliest possible start and latest possible end).

This worked OK, but we get into a bunch of trouble with EditEngine, mostly because each field can be updated individually now. We can't easily tell if an event is all-day or not when reading or updating the start time and end time, and making that easier would introduce a huge amount of complexity.

Instead, when we update the start or end time, we write //two// times:

  - The epoch timestamp of the time the user entered, which is the start time we will use if the event is a normal event.
  - The epoch timestamp of 12:00 AM in UTC on the same date as the //local// date the user entered. This is pretty much like just storing the date the user actually typed. This is what w'ell use if the event is an all-day event.

Then, no matter whether the event is later made all-day or not, we have all the information we need to display it correctly.

Test Plan:
  - Created and edited all-day events.
  - Migrated existing all-day events, which appeared to survive without problems. (Note that events all-day which were created or edited in the last couple of days `master` won't survive this mutation correctly and will need to be fixed.)
  - Created and edited normal, recurring, and recurring all-day events.
  - Swapped back to `stable`, created an event, specifically migrated it forward, made sure it survived with times intact.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16305
2016-07-15 12:24:01 -07:00
epriestley
cf57f6385b Fix some Calendar Event userPHID/hostPHID/"Creator" confusion in searching
Summary: Ref T11326. Align this stuff with "Host" and "hostPHID".

Test Plan: Searched for events by host.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16303
2016-07-14 14:24:05 -07:00
epriestley
08ac49e15a Remove old paged forms
Summary:
Ref T11326. This gets rid of the old multi-paged form stuff used in the last version of Diffusion.

This incidentally removes a callsite for a date control to make it a little easier to simplify them.

Test Plan: Grepped for all removed classes, no more callsites.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16302
2016-07-14 13:05:59 -07:00
epriestley
1c33b70c66 Remove two unused SearchEngine methods
Summary:
Ref T11326. These are last-generation and neither of these have callsites anymore.

(I nuked these since I'm trying to simplify date handling.)

Test Plan: Grepped for callsites.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16301
2016-07-14 13:05:33 -07:00
epriestley
893edf9d95 Make Calendar Event handles slightly more modern
Summary: Ref T11326. Use modern methods instead of building this stuff separately.

Test Plan: Used `E123`, `{E123}`, saw references render normally.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16300
2016-07-14 10:03:42 -07:00
epriestley
3085e52843 Make upcoming events view more viewer-oriented
Summary:
Ref T11326. Try to make this a little more useful:

  - Don't show entire attendee list (not useful?)
  - Show host (useful?)
  - Show your own status prominently (attending vs declined vs invited).
  - Show cancelled events prominently.

Test Plan: {F1723550}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16299
2016-07-14 07:53:00 -07:00
epriestley
2ce37034ad Move event host and times into event subheader
Summary:
Ref T11326. Show this information with a subheader instead of in properties.

Also, slightly simplify the list view.

Test Plan: {F1723539}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16298
2016-07-14 07:50:20 -07:00
epriestley
04a69fa313 Show event icons in header instead of property list
Summary:
Ref T11326. Currently, events show the icon as a property, like this:

> Icon: Default

This is boring and terrible. Show the icon in the header instead:

{F1723530}

Also minor cleanup on active/cancel states.

Test Plan: Viewed an event, saw icon.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16297
2016-07-14 07:47:38 -07:00
epriestley
7c9a74ce04 Make ghost event instances render better on the event list
Summary:
Ref T11326. Currently, we render "E (99)" for ghost instances, which is meaningless and inconsistent.

Render these more sensibly and consistently.

Test Plan: Viewed event list, saw reasonable monograms / object names.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16296
2016-07-14 07:46:46 -07:00
epriestley
2a1b8ce85b For now, hard limit task graph at 100 nodes
Summary:
Ref T4788. One install has some particularly impressive task graphs which are thousands of nodes large.

The current graph is pretty broken in these cases. For now, just render a "too big to show" message. In the future, I'd plan to finesse this (e.g., show parents/children, show links to parents/children, etc).

Test Plan:
  - Viewed a normal task.
  - Set limit to 3, viewed a task with graph size 6, saw an error message.
  - Viewed a revision stack graph (unaffected).

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T4788

Differential Revision: https://secure.phabricator.com/D16295
2016-07-13 21:15:15 -07:00
epriestley
6eaa9faec7 Provide default view and edit policies in Calendar, plus "Event Host" and "Event Invitees"
Summary:
Fixes T9224. This adds:

  - A "Default Edit Policy" and "Default View Policy" to Calendar, similar to other applications.
  - "Event Host" and "Event Invitees" objects policies.

These policies often end up being redundant (the host can always view/edit, the invitees can always view), but they can be more clear than setting "No One", and "Editable By: Event Invitees" is a legitimately useful policy.

Test Plan:
  - Created and edited events.
  - Fiddled with defaults.
  - Tried to remove myself as the event host for an "Editable By: Host" event, got an error ("you wouldn't be able to edit").
  - Tried to remove myself as host/invitee for an "Editable By: Invitees" event, got an error.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9224

Differential Revision: https://secure.phabricator.com/D16294
2016-07-13 15:42:12 -07:00
epriestley
3227292073 Slightly simplify some Paste modular transactions
Summary: Modular transactions have slightly more modern ways to express values now.

Test Plan: Looked at transaction record of a paste.

Reviewers: chad, avivey

Reviewed By: avivey

Differential Revision: https://secure.phabricator.com/D16293
2016-07-13 15:41:19 -07:00
epriestley
439af11e70 Make event hosts editable
Summary:
Fixes T10909. I think this is a generally reasonable sort of capability to expose, although I've made it edit-only for now (when creating an event, you're always the host).

Also clean up some minor leftovers in the code, and a couple of little bugs with recurrence frequencies.

Test Plan: Created an event, edited the host of an event.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10909

Differential Revision: https://secure.phabricator.com/D16292
2016-07-13 15:40:41 -07:00
epriestley
b6daa049de Rename Event "userPHID" to "hostPHID"
Summary: Ref T10909. Ref T9224. We label this field "Host" in the UI; make the storage format consistent.

Test Plan:
  - Viewed month view, day view, detail view of an event.
  - Created a new event, saw myself as the host.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9224, T10909

Differential Revision: https://secure.phabricator.com/D16291
2016-07-13 15:39:55 -07:00
epriestley
8062423271 Respect 12 hour vs 24 hour time formats in Calendar day views
Summary: Fixes T9202.

Test Plan:
  - Viewed day in 12-hour, saw "8:00 PM".
  - Viewed day in 24-hour, saw "16:00".

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9202, T10932

Differential Revision: https://secure.phabricator.com/D16290
2016-07-13 15:39:20 -07:00
epriestley
872bcd4487 Make limits and ranges work better with Calendar event queries
Summary:
Fixes T8911. This corrects several issues which could crop up if a calendar event query matched more results than the query limit:

  - The desired order was not applied by the SearchEngine -- it applies the first builtin order instead. Provide a proper builtin order.
  - When we generate ghosts, we can't do limiting in the database because we may select and then immediately discard a large number of parent events which are outside of the query range.
    - For now, just don't limit results to get the behavior correct.
    - This may need to be refined eventually to improve performance.
  - When trimming events, we could trim parents and fail to generate ghosts from them. Separate parent events out first.
  - Try to simplify some logic.

Test Plan: An "Upcoming" dashboard panel with limit 10 and the main Calendar "Upcoming Events" UI now show the same results.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T8911

Differential Revision: https://secure.phabricator.com/D16289
2016-07-13 15:39:00 -07:00
epriestley
8ade91486c Add calendar.event.search and calendar.event.edit
Summary: Ref T7944. The search method is a bit bare-bones for now, but these substantially work.

Test Plan: Edited events via API; queried events via API.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T7944

Differential Revision: https://secure.phabricator.com/D16288
2016-07-13 10:17:46 -07:00
epriestley
26c6f64fd4 In email, render dates with an explicit timezone offset
Summary:
Fixes T10633. When generating email about a transaction which adjusts a date, render the offset explicitly (like "UTC-7").

This makes it more clear in cases like this:

  - mail is being sent to multiple users, and not necessarily using the viewer's settings;
  - you get some mail while travelling and aren't sure which timezone setting it generated under.

Test Plan: Rendered in text mode, saw UTC offset.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10633

Differential Revision: https://secure.phabricator.com/D16287
2016-07-13 08:32:37 -07:00
epriestley
7b09f5698f Convert Calendar to Modular Transactions
Summary:
Ref T9275. Swaps Calendar over to modular transactions. Theoretically, this has almost no effect on anything.

Ref T10633. I didn't actually do anything here yet, but this gets us ready to put timestamps in email.

Test Plan: Created and edited a bunch of events, nothing seemed catastrophically broken.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275, T10633

Differential Revision: https://secure.phabricator.com/D16286
2016-07-13 07:46:33 -07:00
epriestley
63fec9b97d Restore date validation errors to Calendar
Summary: Ref T9275. I waffled back and forth on these transactions a bit, but put these back here in better working order.

Test Plan: Tried to schedule an event on "taco".

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16285
2016-07-13 07:46:05 -07:00
epriestley
46cf189413 Fix some EditEngine issues with rendering "invite" transactions
Summary:
Ref T9275. We were rendering too many transactions and/or over-rendering invitees.

Clean this logic up a bit:

  - List all before/after invitees.
  - Simplify the lists before rendering.

Test Plan: Viewed an event, edited invitees, got sensible human-readable transactions.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16284
2016-07-13 07:45:35 -07:00
epriestley
ea813985a2 Switch Calendar to EditEngine
Summary:
Ref T9275. This throws away the old EditController and switches fully to EditEngine.

There's still some sketchy behavior (particularly, no JS stuff yet) but I think all the basics work properly.

Test Plan: Created and edited events via EditEngine, everything seemed to work alright.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16283
2016-07-13 07:45:02 -07:00
epriestley
a46a4362db Smooth over a few more transaction compatibility/structure issues with Calendar events
Summary: Ref T9275. This gets things roughly into shape for a cutover to EditEngine, mostly by fixing some problems with "recurrence end date" not being nullable while editing events.

Test Plan: Edited events with EditPro controller, nothing was obviously broken.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16282
2016-07-13 07:44:15 -07:00
epriestley
bac6acb3d1 Make EditEngine form for Calendar Events almost fully-functional
Summary:
Ref T9275. This still has a number of rough edges and other minor problems (no JS on the controls, some date handling control bugs) but I'll smooth those over in future changes.

It does make all the editable transaction types available from EditEngine, technically speaking.

Test Plan: Created and edited events with the "pro" controller, which mostly worked.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16281
2016-07-13 07:43:38 -07:00
epriestley
eebaf58342 Simplify the TYPE_INVITE Calendar Event transaction for EditEngine
Summary:
Ref T9275. Now that TYPE_ACCEPT and TYPE_DECLINE have been separated out, we can simplify TYPE_INVITE.

This now just takes a list of invited PHIDs, uninvites ones that were removed and invites ones that were added. This is simpler, lets more logic live in the Editor, and makes EditEngine/API access easier.

Test Plan: Created events, added and removed invitees. Used comment stacked action and "pro" editor to adjust invitees.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16280
2016-07-13 07:43:06 -07:00