1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-25 08:12:40 +01:00
Commit graph

305 commits

Author SHA1 Message Date
Chad Little
65e964fca1 Make "Core Applications" more reasonable
Summary: Ref T11132, cleaning up what "Core Applications" means.

Test Plan: Visit `/applications/`, see less poseurs.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Maniphest Tasks: T11132

Differential Revision: https://secure.phabricator.com/D16394
2016-08-12 07:57:59 -07:00
epriestley
87f663ef77 Add basic Herald support to Calendar
Summary: Fixes T7939. This doesn't get too fancy, but allows you to write Herald rules against Calendar events.

Test Plan:
  - Wrote an "add red flag to events with party in the name" rule.
  - Created a "mundane meeting", didn't get flagged.
  - Created a "cool party", got flagged.
  - Ran rules from the Herald test console.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T7939

Differential Revision: https://secure.phabricator.com/D16368
2016-08-06 14:37:33 -07:00
Chad Little
11e84c166a Redesign Application Search
Summary: This moves aphront-side-nav to use same table css display as profile nav. Slightly less code to support. Cleans up AppSearch UI, think I've gotten all the edge cases here, but bang on it, can hold until after release cut.

Test Plan: Config, Maniphest, Differential, Diffusion, Home.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D16346
2016-08-01 12:23:36 -07:00
epriestley
2e41c85cc9 Clean up recurring event information on Calendar events
Summary: Ref T11326. This adds prev/next links for recurring events (ala D16179) and moves the "accept/decline" buttons closer to the invite list. This might need some fiddling, but should be a little more human-friendly.

Test Plan: {F1740541}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16339
2016-07-28 10:59:28 -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
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
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
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
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
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
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
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
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
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
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
epriestley
c09e870733 Prepare event dates for EditEngine/API
Summary:
Ref T9275. Currently, the "Start Date", "End Date", and "Recurrence End Date" transcations take a complex value (AphrontFormDateControlValue) and reduce it to an epoch.

Do this a little earlier, since the API will be much more usable if it just passes in epoch timestamps.

Events also have some logic where they rewrite the from date and to date on the actual object for all day events, then undo the changes later. Specifically, if you have an all-day event on "July 24th", the exact start and end times vary based on who is looking at it. Instead of overwriting the persistent `dateFrom` and `dateTo` properties, add separate `viewer` properties to make it easier to keep this stuff straight.

Since this means all-day events get stored in UTC, we need to query/fetch (and then discard) slightly more events. This is perfectly and much simpler to do.

The one weird "UTC" hack in here will get nuked when this moves to EditEngine properly.

Test Plan: Edited times for normal events and all-day events.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16274
2016-07-13 07:42:30 -07:00
epriestley
3a09bb577e Create separate "Accept" and "Decline" transactions for Calendar
Summary:
Ref T9275. Currently, there's a single "invite" transaction type for managing Calendar invites, and it takes a map of invitees to status.

This isn't great for EditEngine or API access, since it lets you set anyone else to any status and we can't reuse as much code as we can with a simpler API.

Make "Accept" and "Decline" separate actions which affect the actor's invite, so "invite" can be a simpler transaction which just invites or uninvites people.

Test Plan:
  - Joined/accepted/declined an event invitation.
  - Edited event invitees.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16272
2016-07-13 07:41:58 -07:00
epriestley
ffdb9f06f8 Move more event fields to EditEngine
Summary:
Ref T9275. This moves description, icon, and cancel/uncancel to EditEngine.

It removes TYPE_SEQUENCE_INDEX and TYPE_INSTANCE_OF_EVENT. These are currently never generated and I do not expect to genereate them (instead, these changes happen automatically when you edit a stub).

Test Plan: Edited an event with normal and pro edit forms.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16264
2016-07-13 07:41:34 -07:00
epriestley
3ab6a7e19f Generate "stub" events earlier, so more infrastructure works with Calendar
Summary:
Ref T9275. When you create a recurring event which recurs forever, we want to avoid writing an infinite number of rows to the database.

Currently, we write a row to the database right before you edit the event. Until then, we refer to it as `E123/999` or whatever ("instance 999 of event 123").

This creates a big mess with trying to make recurring events work with EditEngine, Subscriptions, Projects, Flags, Tokens, etc -- all of this stuff assumes that whatever you're working with has a PHID.

I poked at letting this stuff work without a PHID a little bit, but that looked like a gigantic mess.

Instead, generate an event "stub" a little sooner (when you look at the event detail page). This is basically just an ID/PHID to refer to the instance.

Then, when you edit the stub, "materialize" it into a real event.

This still has some issues, but I think it's more promising than the other approach was.

Also:

  - Removes dead user profile calendar controller.
  - Replaces comments with EditEngine comments.

Test Plan:
  - Commented on a recurring event.
  - Awarded tokens to a recurring event.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16248
2016-07-13 07:41:16 -07:00
epriestley
91a8a6d618 Initial cut of CalendarEditEngine
Summary:
Ref T9275. This builds a Calendar EditEngine which only edits "name".

I'll add more fields, Conduit, etc.,  and move to modular transactions in future changes.

Test Plan: Used `editpro/` URI manually to edit the name of an event.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9275

Differential Revision: https://secure.phabricator.com/D16235
2016-07-13 07:40:57 -07:00
epriestley
7969f66dfe Fully modularize the "Quick Actions" menu
Summary:
Ref T10077. Currently, we issue 6+ queries on every page to build this menu, since the menu is built application-by-application.

Build the menu with dedicated modules instead so a single "EditEngine" module can provide all of them with one query.

I'd like to reduce this to 0 queries but I'm not totally sure what we want to do with this menu.

This change removes these items, because EditEngine can not currently provide them:

  - Calendar: Eventually via EditEngine eventually.
  - Conpherence: Probably via EditEngine, doesn't seem too important.
  - People: Maybe via EditEngine, doesn't seem too important? "Welcome" is likely better?
  - Pholio: Eventually via EditEngine.

It adds a bunch of other items as a side effect:

{F1677151}

This reduces the queries issued on every page by ~5.

This also makes quick create actions visible while logged out (see T7073).

Test Plan:
  - Viewed menu while logged in.
  - Viewed menu while logged out.
  - Viewed standalone version of menu.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10077

Differential Revision: https://secure.phabricator.com/D16045
2016-06-05 10:32:01 -07:00
epriestley
ebd8f3c987 Make translation, timezone and pronoun into real settings
Summary:
Ref T4103. These are currently stored on the user, for historic/performance reasons.

Since I want administrators to be able to set defaults for translations and timezones at a minimum and there's no longer a meaningful performance penalty for moving them off the user record, turn them into real preferences and then nuke the columns.

Test Plan:
  - Set settings to unusual values.
  - Ran migrations.
  - Verified my unusual settings survived.
  - Created a new user.
  - Edited all settings with old and new UIs.
  - Reconciled client/server timezone disagreement.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T4103

Differential Revision: https://secure.phabricator.com/D16005
2016-06-02 06:29:47 -07:00
epriestley
edfc6a6934 Convert some loadPreferences() to getUserSetting()
Summary:
Ref T4103. This doesn't get everything, but takes care of most of the easy stuff.

The tricky-ish bit here is that I need to move timezones, pronouns and translations to proper settings. I expect to pursue that next.

Test Plan:
- Grepped for `loadPreferences` to identify callsites.
- Changed start-of-week setting, loaded Calendar, saw correct start.
- Visited welcome page, read "Adjust Settings" point.
- Loaded Conpherence -- I changed behavior here slightly (switching threads drops the title glyph) but it wasn't consistent to start with and this seems like a good thing to push to the next version of Conpherence.
- Enabled Filetree, toggled in Differential.
- Disabled Filetree, no longer visible in Differential.
- Changed "Unified Diffs" preference to "Small Screens" vs "Always".
- Toggled filetree in Diffusion.
- Edited a task, saw sensible projects in policy dropdown.
- Viewed user profile, uncollapsed/collapsed side nav, reloaded page, sticky'd.
- Toggled "monospaced textareas", used a comment box, got appropriate fonts.
- Toggled durable column.
- Disabled title glyphs.
- Changed monospaced font to 18px/36px impact.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T4103

Differential Revision: https://secure.phabricator.com/D16004
2016-06-02 06:29:20 -07:00
epriestley
8a98868bfb Remove "days fresh" / "days stale" indictator in Differential revision list
Summary:
Ref T10939. I'm not //totally// opposed to the existence of this element, but I think it's the kind of thing that would never make it upstream today. I think this should just be a T418 custom sort of thing in the long run, not a mainline upstream feature.

Overall, I think this thing is nearly useless and just adds visual clutter. My dashboard is about 100% red. This also sort of teaches users that it's fine to let revisions sit for a couple of days, which isn't what I'd like the UI to teach. Finally, removing it helps the UI feel a little less cluttered after the visually busy changes in D15926.

Test Plan: Grepped for removed config. Viewed revision list.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10939

Differential Revision: https://secure.phabricator.com/D15927
2016-05-16 10:47:19 -07:00
lkassianik
bd8969a23c Calendar event list items 'Attending:' field should only show users who have confirmed attendance
Summary: Fixes T8897

Test Plan: Open any list view of Calendar events, every event should only show "Attending: ..." with users who are attending event.

Reviewers: chad, epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: Korvin

Maniphest Tasks: T8897

Differential Revision: https://secure.phabricator.com/D15779
2016-04-21 11:06:49 -07:00
lkassianik
d9275da2d4 Better wording for cancelling/reinstating recurring events
Summary: Fixes T10744

Test Plan: Create recurring event, cancel one instance, cancel the parent event, reinstate event. Wording in the reinstating dialog should be clear about reinstating only instances that haven't been individually cancelled.

Reviewers: chad, epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: Korvin

Maniphest Tasks: T10744

Differential Revision: https://secure.phabricator.com/D15770
2016-04-20 10:10:59 -07:00
Eitan Adler
c9daa2b0ad Consistently refer to 'Projects' as 'Tags'
Summary:
In calendar, dashboard, diffusion, diviner, feed, fund,
maniphest, pholio, ponder, and slowvote use the term 'tags' if possible.

This intenctionally skips diffusion, differential, and the projects application itself.

Ref T10326 Ref T10349

Test Plan: inspection on a running, locally modified, system

Reviewers: avivey, epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: Korvin

Maniphest Tasks: T10835, T10326, T10349

Differential Revision: https://secure.phabricator.com/D15753
2016-04-19 16:48:21 +00:00
epriestley
27104b57c8 Account for raw limits properly in CalendarEventQuery
Summary:
Fixes T8613. This was pretty straightforward, I just never dug into it originally.

`rawResultLimit = 0` just means "no limit", so the fix is to only apply a limit if it is set to some nonzero value.

Also modernize a few pieces of code.

Test Plan: I'm actually not sure this can actually be hit normally? I faked `setGenerateGhosts(true)` into an unrelated query, hit the fatal, then fixed it.

Reviewers: lpriestley, chad

Reviewed By: chad

Maniphest Tasks: T8613

Differential Revision: https://secure.phabricator.com/D15653
2016-04-07 08:39:27 -07:00
Chad Little
8aad862cd4 Normalize casing on property boxes
Summary: Going to render these all normal case instead of all caps, and bump up the font size. Should be more consistent. Yellow if you green anything orange.

Test Plan: grep, lint

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D15645
2016-04-06 15:33:15 -07:00
Chad Little
1f107b8fe0 Update Calendar Edit for new UI
Summary: Updates Calendar Edit UI with new header layout

Test Plan: New Event, Public, Recurring, Edit Event

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D15567
2016-04-01 13:48:53 -07:00
Chad Little
d653b125b5 Add back calendar comment form
Summary: Fix T10544, missed this in testing.

Test Plan: Pull up event, see form, leave comment.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Maniphest Tasks: T10544

Differential Revision: https://secure.phabricator.com/D15437
2016-03-08 08:06:54 -08:00
epriestley
fd9de5d6ec Convert every two-column application except Maniphest to curtain views
Summary: Moves over everything except Maniphest, which has some special behavior.

Test Plan:
  - Viewed a badge.
  - Viewed a calendar event.
  - Viewed a countdown.
  - Viewed a Fund initiative.
  - Viewed a Herald rule.
  - Viewed a macro.
  - Viewed an application.
  - Viewed an owners package.
  - Viewed a credential.
  - Viewed a Ponder question.
  - Viewed a poll.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D15416
2016-03-06 10:44:07 -08:00
epriestley
abb4c03b47 Remove shouldShowSubscribersProperty() from SubscribableInterface
Summary:
Every caller returns `true`. This was added a long time ago for Projects, but projects are no longer subscribable.

I don't anticipate needing this in the future.

Test Plan: Grepped for this method.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D15409
2016-03-06 06:01:36 -08:00
Chad Little
61c45e4927 Update Calendar for PHUITwoColumnView
Summary: Moves calendar event view to PHUITwoColumnView. Tightened up some phui status spacing.

Test Plan: Review Calendar Events, Differential status list.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D15387
2016-03-02 18:12:42 -08:00
Chad Little
f35509e30e Update to use PHUIRemarkupView everywhere possible
Summary: Moves all the one off object calls to PHUIRemarkupView, adds a "Document" call as well (future plans).

Test Plan: Visited most pages I could get access to, but may want extra careful eyes on this diff.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D15281
2016-02-16 14:05:53 -08:00