1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-22 13:30:55 +01:00
Commit graph

13429 commits

Author SHA1 Message Date
epriestley
f4f3b90c87 On tasks, put Task Graph, Mocks and Mentions into a tabgroup
Summary:
Fixes T4788. This change:

  - converts the "Task Graph" into a "Related Objects" tabgroup.
  - makes "Task Graph" the first tab in the group.
  - moves "Mocks" to become a tab.
  - adds a new "Mentions" tab, which shows inbound and outbound mentions.

Primary goal of "mocks" is to give us room for a pinboard/thumbnail view after the next Pholio iteration. Might make sense to make it the default tab (if present) at that point, too, since mocks are probably more important than related tasks when they're present.

Primary goal of "mentions" is to provide a bit of general support for various freeform relationships between tasks: if you want to treat tasks as "siblings" or "related" or "following" or whatever, you can at least find them all in one place. I don't plan to formalize any of these weird one-off relationships in the upstream, although it's vaguely possible that some far-future update might just let you define arbitrary custom relationships and then you can do whatever you want.

Test Plan: {F1906974}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T4788

Differential Revision: https://secure.phabricator.com/D16806
2016-11-06 09:05:14 -08:00
epriestley
17bd483207 Queue large ICS files for background import
Summary: Ref T11801. When a file is larger than 512KB, queue it for background import instead of trying to do it in the foreground, sinc we risk hitting `max_execution_time`.

Test Plan: {F1906943}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11801

Differential Revision: https://secure.phabricator.com/D16805
2016-11-06 07:46:21 -08:00
epriestley
e1566bef63 Fix a Calendar import issue where we looked up attendees by object instead of name
Summary:
Ref T11801. This issue led to the stack trace in T11801#199042.

It wasn't obvious that this was wrong because the recover-on-duplicate-key code made it work correctly.

Test Plan: Imported an event with external attendees with no warnings in the log.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11801

Differential Revision: https://secure.phabricator.com/D16804
2016-11-05 11:12:20 -07:00
epriestley
bd3233d3ab Use a more conventional placement of parentheses
Auditors: avivey
2016-11-04 16:59:09 -07:00
epriestley
90fb8a1516 Fix an issue with editing application default policies in Calendar
Summary: Ref T11816. We're running this code on empty events which haven't been initialized and don't have a source attached -- just use a more explanatory check which doesn't need anything attached.

Test Plan: Edited default Calendar policies.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11816

Differential Revision: https://secure.phabricator.com/D16803
2016-11-04 16:55:56 -07:00
epriestley
e337029769 Allow users to mark themselves as "Available", "Busy" or "Away" while attending an event
Summary:
Ref T11816.

  - Now that we can do something meaningful with them, bring back the yellow dots for "busy".
  - Default to "busy" when attending events (we could make this "busy" for short events and "away" for long events or something).
  - Let users pick how to display their attending status on the event page.
  - Also show which event the user is attending since I had to mess with the cache code anyway. We can get rid of this again if it doesn't feel good.

Test Plan:
{F1904179}

{F1904180}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11816

Differential Revision: https://secure.phabricator.com/D16802
2016-11-04 16:55:44 -07:00
epriestley
ac8b156e4b Raise ICS warnings in Phabricator on ICS import
Summary: Ref T11816. Depends on D16800. Show warnings generated by ICS import in the UI.

Test Plan: {F1904122}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11816

Differential Revision: https://secure.phabricator.com/D16801
2016-11-04 16:36:55 -07:00
epriestley
c2565d5e24 Fix a bug with creating Phortune merchant accounts without applying an email address transaction and some null field issues
Summary:
When Phortune merchant accounts are created via mechanisms other than the web UI (for example, by Phacility unit tests) this validation check may fail.

Transactions are validated even if no transactions of the given type are being applied, to allow the editor to raise errors like "Name is required!".

If there's no TYPE_INVOICEEMAIL transaction, we'll get called with empty `$xactions` and fail on `strlen($new_email)` because the variable is never defined.

As a secondary issue, if contactInfo, invoiceEmail or invoiceFooter are not provided the record will fail to insert (none of these are nullable).

Test Plan: Ran Phacility unit tests, got a clean result for new instance creation.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D16798
2016-11-04 09:52:48 -07:00
epriestley
0f1785c0aa Allow EditEngine to build NUX buttons that point at the right place
Summary:
Fixes T11812.

  - Pull the logic for building the "Create Whatever" dropdown out.
  - Use it to generate NUX buttons, too.
  - Use the new logic in Paste and Maniphest.

Test Plan:
  - Viewed Paste NUX, button worked.
  - Viewed Maniphest NUX with multiple create forms, button worked.

Reviewers: chad, avivey

Reviewed By: avivey

Subscribers: avivey

Maniphest Tasks: T11812

Differential Revision: https://secure.phabricator.com/D16797
2016-11-04 09:51:25 -07:00
epriestley
e4c6ae5345 Smooth out various transaction/editing behaviors for Calendar
Summary:
Ref T11809.

  - Allow users to remove the "Until" date from recurring events.
  - When removing "Until", show a sensible string ("...set this event to repeat forever.")
  - When users go through the "Make Recurring" workflow, don't require them to explicitly select "Recurring: Recurring" from the dropdown. This intent is clear from clicking "Make Recurring".
  - When editing "All Future Events", don't literally apply date changes to them, since that doesn't make sense. We update the template, then reschedule any events which haven't been edited already. I think this is what users probably mean if they make this edit.
  - When creating an event with a non-default icon, don't show "alice changed the icon from Default to Party.".
  - Hide the "recurring mode" transaction, which had no string ("alice edited this Event.") and was redundant anyway.
  - Also, add a little piece of developer text to make hunting these things down easier.

Test Plan: Edited various events, parents, children, made events recur, set until, unset until, viewed transactions, rescheduled parents, rescheduled children.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11809

Differential Revision: https://secure.phabricator.com/D16796
2016-11-03 11:03:20 -07:00
epriestley
e9b861ff15 Write a basic Calendar user guide
Summary:
Ref T11809. Roughly documents most of the tricky/unintuitive stuff.

Also fixes a bug with "Make Recurring" with no "Until" date.

Test Plan: Read document.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11809

Differential Revision: https://secure.phabricator.com/D16792
2016-11-02 14:48:29 -07:00
epriestley
29313372e7 Improve some commenting/editing behaviors for recurring events
Summary:
Ref T11809. Currently, commenting on a recurring event hits the same "one or all?" dialog that other edits do.

For comments and edits submitted via the comment widget, we can safely assume that you mean "just this one", since it doesn't really make sense to try to bulk-edit an event from that UI.

Test Plan: Commented on a recurring event parent and an event in the series.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11809

Differential Revision: https://secure.phabricator.com/D16795
2016-11-02 14:08:55 -07:00
epriestley
64cf9204c1 In Calendar, only include the event description in the original event mail
Summary: Ref T11809. This makes the mail more consistent with Differential and Maniphest, which only include additional details in the first mail in the thread.

Test Plan:
  - Created an event with a description.
  - First mail included it.
  - Followups did not.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11809

Differential Revision: https://secure.phabricator.com/D16794
2016-11-02 13:46:05 -07:00
epriestley
c9510cc118 Make it more clear that red dots next to usernames mean Calendar availability
Summary:
Ref T11809. We show a red dot next to a username to indicate that the user is away (on vacation, in a meeting, etc).

It's not very obvious what this means unless you know that's what it is: when you click the username or view a hovercard, there's no visual hint about what the red dot means. It does say "Away", but there is a lot of information and it doesn't visually connect the two.

Connect the two visually by putting a red dot next to the "Away" bit, too.

Test Plan:
Here's my version of it, this feels OK to me but could maybe be more designed:

{F1893916}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11809

Differential Revision: https://secure.phabricator.com/D16791
2016-11-02 13:45:43 -07:00
epriestley
bf0004744b Move "Calendar" above "Badges" on user profiles
Summary:
Ref T11809. As we move toward unprototyping, this panel is probably more relevant/dynamic/interesting more often than the badges panel, I think?

Particularly, I want to make the red dots a little easier to understand, and I think putting this above the fold will help aid discovery (red dot -> click -> see red dot -> see "away until ..." -> see calendar -> "oh they're at a meeting"?).

This is entirely a product/subjective thing so I'm fine with not doing it or using a different order.

I think there's maybe even an argument for putting this above "Projects", but "Projects" feels more core to me, at least for now.

Test Plan: Viewed a user profile, saw "Calendar" above "Badges".

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11809

Differential Revision: https://secure.phabricator.com/D16790
2016-11-02 13:13:45 -07:00
epriestley
713f8fb373 Fix a bug which could cause imported events to set themselves as their own parents
Summary: Ref T11808. This variable is wrong, and would sometimes cause events to set themsevles as their own parents. They would then fail to load, and disrupt cursor paging.

Test Plan:
  - Reproduced T11808 locally by reloading test data 2+ times, creating events with themselves as their own parents.
  - Appplied fix.
  - Nuked data, reloaded, no more self-parents.
  - Test datafile: {F1894017}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11808

Differential Revision: https://secure.phabricator.com/D16793
2016-11-02 11:44:09 -07:00
epriestley
3f2f81a1c8 Remove obsolete Calendar event date storage fields
Summary: Ref T11809. These have been replaced with more flexible storage that accommodates a wider range of behaviors, including those in the ICS format and RRULEs.

Test Plan:
  - Ran migration.
  - Viewed, created, edited events.
  - Grepped for all removed names/symbols.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11809

Differential Revision: https://secure.phabricator.com/D16789
2016-11-02 09:49:08 -07:00
epriestley
6982bded71 Remove ancient "Holiday" storage
Summary:
Ref T11809. This came out of Facebook many years ago for computing the number of business days that revisions had been stale.

We removed the little staleness marker a few months ago and haven't seen complaints about it.

If we did holidays now it would make sense to integrate them more directly with Calendar as real events, but I have no plans to pursue this anytime soon. It's easy enough to add the federal holidays manually (~5 minutes of work per year?) if you want them, and they're commentable/editable and you can add local holidays if you're not in the US.

Test Plan:
  - Ran `bin/storage upgrade -f`.
  - Grepped for `CalendarHoliday`.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11809

Differential Revision: https://secure.phabricator.com/D16788
2016-11-01 16:03:44 -07:00
epriestley
191b9398a5 Fix some minor Calendar issues, including a paging issue on imports
Summary:
Fixes T11808. I couldn't reproduce the issue there locally so I'm just cheating a little bit until a better reproduction case shows up.

We don't need to do a full load here anyway, and testing for any row is more efficient.

Test Plan: Poked around imports without issues, but couldn't reproduce this problem locally.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11808

Differential Revision: https://secure.phabricator.com/D16787
2016-11-01 14:40:30 -07:00
epriestley
3e15e0b980 Store more datetime information on Calendar transactions and improve rendering behaviors
Summary:
Fixes T11805. Depends on D16785. This generally tries to smooth out transactions:

  - All-day stuff now says "Nov 3" instead of "Nov 3 12:00:00 AM".
  - Fewer weird bugs / extra transactions.
  - No more silly extra "yeah, you definitely set that event time" transaction on create.

Test Plan: Edited events; changed from all-day to not-all-day and back again, viewed transaction log.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11805

Differential Revision: https://secure.phabricator.com/D16786
2016-11-01 13:36:46 -07:00
epriestley
6b16f930c4 Automatically send (not-so-great) email notifications for upcoming events
Summary: Ref T7931. This is still quite rough, but should technically send vaguely-useful email as part of the standard trigger infrastructure.

Test Plan: Ran `bin/phd start`, created an event shortly, saw reminder email send in `bin/mail list-outbound`.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T7931

Differential Revision: https://secure.phabricator.com/D16784
2016-11-01 13:24:40 -07:00
epriestley
6e6ae36dcf Add a skeleton for Calendar notifications
Summary:
Ref T7931. I'm going to do this separate from existing infrastructure because:

  - events start at different times for different users;
  - I like the idea of being able to batch stuff (send one email about several upcoming events);
  - triggering on ghost/recurring events is a real complicated mess.

This puts a skeleton in place that finds all the events we need to notify about and writes some silly example bodies to stdout, marking that we notified users so they don't get notified again.

Test Plan:
Ran `bin/calendar notify`, got a "great" notification in the command output.

{F1891625}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T7931

Differential Revision: https://secure.phabricator.com/D16783
2016-11-01 10:41:15 -07:00
epriestley
a0ea31f47f When users edit recurring events, prompt to "Edit This Event" or "Edit All Future Events"
Summary:
Fixes T11804. This probably isn't perfect but seems to work fairly reasonably and not be as much of a weird nonsense mess like the old behavior was.

When a user edits a recurring event, we ask them what they're trying to do. Then we more or less do that.

Test Plan:
  - Edited an event in the middle of a series.
  - Edited the first event in a series.
  - Edited "just this" and "all future" events in various places in a series.
  - Edited normal events.
  - Cancelled various events.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11804

Differential Revision: https://secure.phabricator.com/D16782
2016-10-31 16:38:32 -07:00
epriestley
208f8ed526 Support "Edit just this event" on the parent event in a series
Summary:
Ref T11804. This one is messy because we have to fork the //next// event, possibly creating it first.

Then we can edit the parent normally.

Test Plan: Cancelled the first event in a series, only that one cancelled.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11804

Differential Revision: https://secure.phabricator.com/D16781
2016-10-31 15:30:53 -07:00
epriestley
b084efb362 Record a "series parent PHID" on Calendar events that retains relationships after forks
Summary:
When you edit "X and all future events", X becomes the new parent of an event series.

Currently, it loses its relationship to its original parent. Instead, retain that relationship -- it's separate from the normal "parent", but we can use it to make the UI more clear or tweak behaviors later.

This mostly just keeps us from losing/destroying data that we might need/want later.

Test Plan:
  - Ran migrations.
  - Cancelled "X and all future events", saw sensible-appearing beahvior in the database for "seriesParentPHID".

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D16780
2016-10-31 15:30:34 -07:00
epriestley
f44a9a4e48 Remove "isCancelledEvent()" wrapper on Calendar Events
Summary: Ref T11804. The field now reads the correct value directly and we don't need this wrapper.

Test Plan: Poked around Calendar without explosions.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11804

Differential Revision: https://secure.phabricator.com/D16779
2016-10-31 15:30:21 -07:00
epriestley
91089acbe5 Begin navigating the mess that is edits to recurring events
Summary:
Ref T11804. This puts us on a path toward some kind of reasonable behavior here.

Currently, cancelling recurring events makes approximately zero sense ever in any situation.

Instead, give users the choice to cancel just the instance, or all future events. This is similar to Calendar.app. (Google Calendar has a third option, "All Events", which I may implement).

When the user picks something, basically do that.

The particulars of "do that" are messy. We have to split the series into two different series, stop the first series early, then edit the second series. Then we need to update any concrete events that are now part of the second series.

This code will get less junk in the next couple of diffs (I hope?) since I need to make it apply to edits, too, but this was a little easier to get started with.

Test Plan:
Cancelled an instance of an event; cancelled "All future events".

Both of them more or less worked in a reasonble way.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11804

Differential Revision: https://secure.phabricator.com/D16778
2016-10-31 14:20:55 -07:00
epriestley
8e5437226f Make calendar intepret all-day dates in a more consistent way
Summary:
In ICS, an event on "Nov 1" starts on "2016-11-01" and ends on "2016-11-02".

This is convenient for computers, but this isn't what users expect to enter in date controls. They expect to enter "nov 1" to "Nov 1" for a one-day, all-day event. This is consistent with other applications.

Store the value the user entered, but treat it as the first second of the next day when actually using it if the event is an all day event.

Test Plan:
Mucked around with multi-day all-day events, recurring all-day events, imports, etc. Couldn't catch any weird/unintuitive stuff anymore offhand.

(Previously, entering "Nov 1" to "Nov 2" created a one-day event, which was unclear.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D16777
2016-10-31 14:19:35 -07:00
epriestley
f7b0c09ac4 Make the "All Day Event" control use a checkbox instead of a dropdown
Summary:
This feels a little cleaner:

  - Clean up transaction log a bit.
  - Use a checkbox instead of a two-option dropdown.

This is a little messy because the browser doesn't send anything if the user submits a form with an un-clicked checkbox.

We now send a dummy value ("Hey, there's definitely a checkbox in this form!") so the server can figure out what to do.

Test Plan:
  - Edited all-dayness of an event.
  - Viewed transaction log.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D16776
2016-10-31 14:18:59 -07:00
epriestley
182611ef7e Schedule monthly events on the 29th, 30th or 31st relative to the end of the month
Summary:
Ref T11326. If you scheudle a monthly event on the 31st, the default behavior of RRULE means that it only occurs in months with 31 days.

This is actually how Google Calendar and Calendar.app both work: if you schedule a monthly event on the 31st, you get about six events per year.

This seems real confusing and bad to me?

Instead, if the user schedules a monthly event on the 29th, 30th or 31st, pretend they scheduled it on the "last day of the month" or "second-to-last day of the month" or similar, so they always get 12 events per year.

This could be slightly confusing too, but seems way less weird than not getting an event every month.

Test Plan: Scheduled events on the 31st of October, saw them occur in November too after the patch.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16775
2016-10-31 14:13:50 -07:00
epriestley
850fcf0207 Move event recurrence controls to a separate page on the workflow
Summary:
Ref T11326. Currently, the "Create Event" form is pretty wordy. One particular culprit is the "recurring" controls, which are (presumably) rarely used and visually complex.

  - Reflow the default form to hopefully feel a little better.
  - Move recurrence stuff to a separate workflow.

Test Plan:
{F1891355}

{F1891356}

{F1891357}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16774
2016-10-31 14:13:36 -07:00
William Light
ee834c5958 oauthserver: get client ID/secret from HTTP auth
Summary:
This adds the ability for Phabricator's OAuth server implementation to use HTTP basic auth for the client ID and secret and brings it in line with the OAuth 2.0 specification in this respect.

Fixes T11794

Test Plan: Fixes my use case. Shouldn't impact other use-cases.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: 0, Korvin

Maniphest Tasks: T11794

Differential Revision: https://secure.phabricator.com/D16763
2016-10-31 08:22:52 -07:00
epriestley
5e784c998b Fix some extra "changed the start time of this event" transactions
Summary: Ref T11326. Since we were missing an `(int)` cast here, the code ended up thinking that changing `12345` to `"12345"` was an edit. It isn't.

Test Plan: Created/edited events, no more extra "changed start time from X to the same X" transaction clutter.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16773
2016-10-30 10:21:22 -07:00
epriestley
e1a9b76945 Give organizers in ICS exports a dummy email address to placate Gmail
Summary:
Ref T10747. In the in-email ICS event card that Gmail shows, it has a "Who" field which reads "Unknown Organizer*" if the URI for the organizer isn't email-address-like.

Previously, we used a URI like `https://phabricator.install.com/p/username`, which I think is OK as far as RFC 5545 is concerned, but Gmail doesn't like it.

Instead, use `PHID-USER-asdfa@phabricator.install.com`, which doesn't go anywhere, but makes Gmail happy. Users don't normally see this URI anyway.

Test Plan:
Got a readable "Who" in Gmail when importing an event exported from Calendar:

{F1890571}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16772
2016-10-30 09:20:54 -07:00
epriestley
d9c91f857c Apply a TYPE_CREATE transaction when importing events to improve strings in timeline
Summary: Ref T10747. This turns on the newer EditEngine behavior so we get a nice "X created this event." transaction, instead of an "X renamed this from <nothing> to Event Name."

Test Plan: Imported an event, saw a nice timeline.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16771
2016-10-30 09:20:15 -07:00
epriestley
96b064b7e9 Properly import all-day events in Calendar
Summary: Ref T10747. The transaction version of this copies the "all day" flag over properly, but this non-transaction version needs to copy it explicitly.

Test Plan: Imported an all-day event, saw it come in as all-day.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16770
2016-10-30 09:19:58 -07:00
Chad Little
5fd79479ec Add a basic invoice view for printing to Phortune
Summary: Makes a more complete PDF looking invoice form for printing in Phortune.

Test Plan: Make an invoice, click print view, print.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D16762
2016-10-29 17:46:47 -07:00
epriestley
1993005651 Fix a variant translation issue
Summary: Fixes T11799. This string is varying on the first parameter, but should vary on the second parameter.

Test Plan: Ran `bin/garbage set-policy ...`, saw proper translation.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11799

Differential Revision: https://secure.phabricator.com/D16769
2016-10-29 17:12:33 -07:00
epriestley
1e488e9277 When importing events, delete events which have been removed on the other end
Summary: Ref T10747. If stuff has been deleted on the other calendar, delete it on ours.

Test Plan:
Imported with deletion, saw deletions:

{F1889689}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16768
2016-10-28 18:14:50 -07:00
epriestley
1014a27717 Document Calendar imports
Summary:
Ref T10747.

  - Adds import documentation.
  - Adds import/export docs to the help menu.
  - Removes some weird/old/out-of-date information from the general user guide, which I'll rewrite later.

Test Plan: Read documentation somewhat thoroughly.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16766
2016-10-28 18:14:08 -07:00
epriestley
2bbddb8c0f Improve some setInitialValue() behavior for PhortuneMerchants
Summary:
This fixes the permissions issue with D16750, which is actually not really a permissions issue, exactly.

This is the only place anywhere that we use a tokenizer field //and// give it a default value which is not the same as the object value (when creating a merchant, we default it to the viewer).

In other cases (like Maniphest) we avoid this because you can edit the form to have defaults, which would collide with whatever default we provide. Some disucssion in T10222.

Since we aren't going to let you edit these forms for the forseeable future, this behavior is reasonable here though.

However, it triggered a sort-of-bug related to conflict detection for these fields (see T4768). These fields actually have two values: a hidden "initial" value, and a visible edited value.

When you submit the form, we compute your edit by comparing the edited value to the initial value, then applying adds/removes, instead of just saying "set value equal to new value". This prevents issues when two people edit at the same time and both make changes to the field.

In this case, the initial value was being set to the display value, so the field would say "Value: [(alincoln x)]" but internally have that as the intitial value, too. When you submitted, it would see "you didn't change anything", and thus not add any members.

So the viewer wouldn't actually be added as a member, then the policy check would correctly fail.

Note that there are still some policy issues here (you can remove yourself from a Merchant and lock yourself out) but they fall into the realm of stuff discussed in D16677.

Test Plan: Created a merchant account with D16750 applied.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D16764
2016-10-28 14:54:13 -07:00
epriestley
a792faf78d Use "book" instead of "life ring" icon for global help menu
Summary: This is more consistent with the icon we use for documentation elsewhere.

Test Plan: Looked at the icon, had an easier time guessing it meant "documentation".

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D16765
2016-10-28 14:33:18 -07:00
Chad Little
0c9ecf8351 Update Phortune Merchant to EditEngine
Summary: Converts PhortuneMerchant to EditEngine.

Test Plan: Edits existing merchants fine, same issue as Conpherence when making new ones with permissions.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D16750
2016-10-28 14:15:26 -07:00
Chad Little
c3809b0d59 Add a Merchant logo to Phortune
Summary: Is a logo. For merchants.

Test Plan: Set a new logo, remove it. See on list.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Maniphest Tasks: T7607

Differential Revision: https://secure.phabricator.com/D16751
2016-10-28 13:56:35 -07:00
epriestley
09775279a9 Support arbitary event invitees when importing events
Summary:
Ref T10747. When we import a ".ics" file, represent any attendees as simple external references.

For consistency with other areas of the product, I've avoided disclosing email addresses. We'll try to get a real name if we can.

(We store addresses and could expose or use them later, or do some kind of masking junk like "epr...ley@g...l.com" which is utterly impossible to figure out.)

Test Plan: {F1888367}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10747

Differential Revision: https://secure.phabricator.com/D16759
2016-10-27 13:27:58 -07:00
epriestley
8e9c20c9ae Make event invitees behave a little better for stub/ghost events
Summary:
Ref T11326. Currently:

  - The month view and day view (ghosts) don't show that you're invited to a child event.
  - The detail view copies the invite list, including attending status, but only //after// it shows the page for the first time.

Instead, for now, just do this:

  - Ghosts/stubs use the parent invite list, but treat everyone as "invited".
  - Materializing a stub just saves the list as-is (i.e., invited, not a copy of attending/declined/etc).

This behavior may need some refining eventually but is at least reasonable (not obviously bad/buggy).

Test Plan:
  - Viewed month/day views, now shown as "invited".
  - Viewed detail view, now invitee list shows up properly.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11326

Differential Revision: https://secure.phabricator.com/D16758
2016-10-27 13:08:56 -07:00
epriestley
12d29d8206 Fix a Phortune bug where an invalid viewer could sometimes be selected for billing a subscription
Summary:
A live instance hit the scenario described in the comment, where an out-of-date user was being selected as the actor.

Since they were no longer an account member, they could not see the payment method and autopay was failing.

Instead, select a relatively arbitrary user who is a current, valid, non-disabled member.

Test Plan: Ran subscriptions with `bin/worker execute ...`, saw it select a valid actor.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D16757
2016-10-26 15:54:04 -07:00
epriestley
0f800a3cd8 In Phabricator, drop PhutilClassMap caches after loading additional libraries
Summary:
Depends on D16755. Right now, we build a setup check map (to run preflight checks), then later load libraries.

This means any checks included in third-party libraries don't get added to the map, and no longer run.

(These are rare, but Phacility has a couple).

Instead, delete the caches after loading extra libraries.

Test Plan: With this and D16755, re-ran setup checks and saw Phacility setup checks run.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D16756
2016-10-26 15:46:33 -07:00
epriestley
4c3f09a6a6 Suggest better start/end datetimes for Calendar events
Summary:
Fixes T11638.

  - Fix a regression: I broke this "round to the nearest hour" code a while ago while fiddling with datetimes.
  - Improve a beahvior: from the day view, make the menu-bar "Create Event" button default to creating an event on the day you were viewing.

Test Plan: Created events from month and day views, got nice round numbers and proper day suggestions.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11638

Differential Revision: https://secure.phabricator.com/D16754
2016-10-26 13:10:29 -07:00
epriestley
7cb44bcee6 Don't allow "Start Time" / "End Time" in Calendar event forms to be locked or have defaults assigned
Summary: Fixes T11733. This fixes the issue by working around it, but it isn't useful to set these fields to a default value anyway.

Test Plan: Created a default Calendar form, set some other defaults, created an event, stuff no longer exploded.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11733

Differential Revision: https://secure.phabricator.com/D16753
2016-10-26 13:10:18 -07:00