Summary: Saved inline comments are now shown for images.
Test Plan: Verified that inline comments are loaded and shown.
Reviewers: epriestley
CC: aran, Korvin
Maniphest Tasks: T2446
Differential Revision: https://secure.phabricator.com/D4866
Summary:
This masks possible configuration issues and slightly degrades functionality
with the tradeoff of having differential work when phabricator isn't quite
configured correctly.
Test Plan:
remove directory for a repository, load differential revision from that repo,
and see differential load.
Reviewers: epriestley, vrana
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2512
Differential Revision: https://secure.phabricator.com/D4859
Summary: I'm not super happy with the prettiness of the code, but I wasn't able to come up with a good way to clean it up. Happy for suggestions.
Test Plan: sent message to btrahan@phabricator.dev from gmail. Copied raw email and piped it to mail_handler.php -- it created a conpherence! Repeated but sent to btrahan and xerxes and noted that the conpherence was created for both users
Reviewers: epriestley, chad
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2431
Differential Revision: https://secure.phabricator.com/D4854
Summary: Resolves submit issues in IE7, scrollbars in IE7 and homepage layout issues in IE7 and IE8.
Test Plan: used IE7 and IE8. Logged in, bounced around. Checked Chrome as well.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2469, T2470
Differential Revision: https://secure.phabricator.com/D4853
Summary: pre-patch, when you upload a photo if the conphernece has a name it gets cleared. Post patch this no longer happens. Patch also makes the case where you delete the conpherence name have more sensical text.
Test Plan: named a conpherence, uploaded an image, verified the name stayed the same. Deleted a conpherence name by changing the text to nothing and verified it work correctly, including having good transaction text.
Reviewers: epriestley, chad
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2399
Differential Revision: https://secure.phabricator.com/D4852
Summary:
- Use PhutilURI to correct for specifying "https://yourname.campfire.com/" instead of "https://yourname.campfire.com".
- Use HTTPSFuture to get logging via `--trace` and error detection (CA stuff should be OK since 37signals has real certs).
- On destruction, only try to leave rooms we've actually joined.
Test Plan: Setup a bot, had it join a room, talked to it.
Reviewers: indiefan
Reviewed By: indiefan
CC: aran
Differential Revision: https://secure.phabricator.com/D4849
Summary: Drafts are saved as inline comments for images when user comments mock.
Test Plan: Verified that drafts receive transactionphid when user comments mock.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2446
Differential Revision: https://secure.phabricator.com/D4850
Summary:
Decided the best approach for refactoring the message/command stuff would be to actually start implementing the campfire adapter to get a better idea of what the abstractions should look like. It feels awkward and unwieldy trying to maintain the irc command interface (notice the message instantiation in the `processReadBuffer()` method. However, i'm still not clear what the best approach is without requiring a re-write of nearly all the existing handlers and defining essentially a custom dsl on top of irc's.
I suppose given that alternative, implementing to irc's dsl doesn't sound all that bad. Just feels like poor coupling.
Also, I know that there is some http stuff in libphutil's futures library, but the https future is shit and I need to do some custom curlopt stuff I wasn't sure how to do with that. But if you think this should be refactored, let me know.
I tested this with the ObjectHandler (messages with DXXX initiate the bot to respond with the title/link just as with irc), but beyond that, I haven't tried any of the other handlers, so if there are complications you think i'm going to run into, just let me know (this is one of the reasons for requesting review early on).
Also, this diff is against my last one, even though that hasn't been merged down yet. It was starting to get large and I'd prefer to keep to two conversations separate.
Fixing some lint issues.
Test Plan: Ran the bot with the Object Handler in campfire and observed it behaving properly.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2462
Differential Revision: https://secure.phabricator.com/D4830
Summary:
The selection reticle in Pholio is functional but not very pretty right now. Make it look a little nicer.
- Using `box-sizing: border-box;` allows us to get rid of the `x - 1` and `y - 2` stuff.
- I draw the reticle with two elements: one mostly-transparent which creates a fill, and one fully opaque to create a strong dashed border.
Test Plan: {F31803}
Reviewers: ljalonen, chad
Reviewed By: chad
CC: aran, kchr
Differential Revision: https://secure.phabricator.com/D4836
Summary: Bulk process markup instead of doing them one at a time. Fixes T2504.
Test Plan: Viewed service profile, saw a single call for all the cache entries.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2504
Differential Revision: https://secure.phabricator.com/D4844
Summary: ...i tend to forget to do this for some reason. my bad.
Test Plan: NA
Reviewers: epriestley, chad
Reviewed By: chad
CC: aran, Korvin
Maniphest Tasks: T2503
Differential Revision: https://secure.phabricator.com/D4840
Summary:
mainly, this adds the image cropper - yay!
- also removes the file image from the handle stuff I added in V1. now we do all this crazy photo stuff.
Test Plan:
- uploaded a photo by dragging to header and noted 120 x 80 showed up on reload
- uploaded a photo by dragging to edit dialogue spot and noted 120 x 80 showed up on reload
- cropped a photo - noted it cropped right
- cropped a photo again and again and again - seems like it crops okay
Reviewers: epriestley, chad
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2418, T2399
Differential Revision: https://secure.phabricator.com/D4790
Summary: If a file isn't a viewable image, don't try to figure out metadata (size, etc.) when rendering a `{F...}` tag in Remarkup.
Test Plan: Uploaded a .rtf, added it as `{F1}` in a new Maniphest task, saw no errors in the dark console.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2479
Differential Revision: https://secure.phabricator.com/D4837
Summary: Fixes T2474. Adds a storage dummy storage engine for unit tests, and adds a couple of simple tests for basic file storage.
Test Plan: Ran `arc unit` to execute unit tests.
Reviewers: kwadwon
Reviewed By: kwadwon
CC: aran
Maniphest Tasks: T2474
Differential Revision: https://secure.phabricator.com/D4777
Summary:
- Make the warning describe rationale and point at the MySQL manual explicitly.
- Add a reference to the developer mode config, in case the user wants to resolve the probelm by disabling developer mode.
- Now that the message is huge, provide a summary.
- Move from "Database" to "MySQL" setup checks -- this is kind of arbitrary, but the former is used for fatals (pre-install) and the latter for warnings (post-install) right now. This has no practical impact on anything and is purely stylistic.
Test Plan:
{F31798}
{F31799}
Reviewers: edward, blc
Reviewed By: edward
CC: aran
Differential Revision: https://secure.phabricator.com/D4835
This is kind of gross, but breaking some menus right now which end up with double-`''` keys. The current meaning of setKey(null) is different from not calling it (it means `setKey('')`).
This should be fixed more reasonably but there's a lot of legacy cruft in PhabricatorSideNavFilterView.
Auditors: btrahan
Summary: Comment draft is now saved
Test Plan: Verified that draft is saved
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin, chad
Maniphest Tasks: T2446
Differential Revision: https://secure.phabricator.com/D4831
Summary:
We've been building a Jenkins plugin that allows you to use your Phabricator login details in Jenkins using the inbuilt OAuthServer. I noticed that when making a request to /oauthserver/auth/?client_id=&response_type=code I get an error back from the server.
I've traced this down to two bugs in PhabricatorOAuthServerAuthController, the first causes a null value error on $access_token_uri, and the second fails on userHasAuthorizedClient without a $scope array.
Test Plan: Go to /oauthserver/auth/?client_id=<client_id>&response_type=code and get a valid authorization code back
Reviewers: epriestley, btrahan
Reviewed By: btrahan
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4808
Summary:
After D4825, this information is often available to us in a safe way. Provide it explictly.
This removes or reduces functionality in some cases, but I think we can plug those holes with Conpherence addresses and/or explicit user acknowledgement/config.
Test Plan: Patched a commit with `arc patch` and got the original address out.
Reviewers: btrahan, edward, vrana
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D4828
Summary:
Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh.
First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts?
Secondly, a few notes, design review requests on the changes i did make:
# Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config.
# Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners.
# Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice?
That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is.
Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2462
Differential Revision: https://secure.phabricator.com/D4757
Summary: do so via event engine. note different order now...
Test Plan: toggled "show beta applications" to off and noted that Conpherence disappeared. Otherwise noted that links showed.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2424
Differential Revision: https://secure.phabricator.com/D4708
Summary: i think the DOM changed in conpherence with the menu upgrades. just noticed that when you select a new conpherence the old one is not de-selected. this fixes it by updating the javascript to ascend one node higher and then use DOM.scry with the right data sigil to get the nodes
Test Plan: read some messages, noted only the one I was reading had the entry highlighted in the left.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2399
Differential Revision: https://secure.phabricator.com/D4819
Summary:
Fixes T2482. After D4792, menus have more formal structure, but previously we were just shoving some `<div>` into the middle of the thing. This no longer works correctly, since we end up with `<div class="nice-formal-div"><div></div>`.
Just put IDs on all the items we're going to show/hide instead so we don't have to render any half-tags.
Test Plan: Home page show/hide works again.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2482
Differential Revision: https://secure.phabricator.com/D4810
Summary: this broke when I moved sorting to the editor. Turns out you can't have custom hooks for the comment transaction, and thus I couldn't update participation inside the editor. This fixes this by removing the empty switch statement for the transaction type inside the parent class editor. This should have no effect other than fixing Conpherence. Note that conpherences will need another message, etc for a given conphernece to fix itself.
Test Plan: Conpherence threads were updated properly!
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2399
Differential Revision: https://secure.phabricator.com/D4817
Summary:
this was originally "just" adding the icons like I had bundled into D4790. It morphed a bit though and does a few things
- adds the icons
- cleans up widget CSS generally a bit so scrolling always works
- phutil_tag -- probably was a bad idea but I wanted to play with it. I think its harder to not break conpherence when you land the branch now maybs. Still up for fixing it immediately post land though.
Test Plan: played with conphernece a bit. Used FF and Chrome to verify CSS was looking okay-ish.
Reviewers: epriestley, chad
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2399
Differential Revision: https://secure.phabricator.com/D4814
Summary: T2326 tells the tale. this is the fix.
Test Plan: verified that queries that shouldn't be sortable weren't. also had a phlog in there a bit to sanity check things faster
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2326
Differential Revision: https://secure.phabricator.com/D4816
Summary:
See D4812.
- This preference disables the file tree completely.
- It defaults off, so users who want it will have to go turn it on.
- Maybe slightly cleaner would be doing this if the tree was hidden and then ajaxing it in if you press "F", but that's complicated and I don't want to bother.
- Generally, I think this element is useful to something like 5% of users and not useful to 95%.
Test Plan: Enabled and disabled file tree. Looked at commits and revisions; verified they reflected the setting correctly.
Reviewers: vrana
Reviewed By: vrana
CC: aran
Differential Revision: https://secure.phabricator.com/D4813
Summary: This is the most requested feature in FB by far.
Test Plan:
Toggled, verified that data are saved.
Reloaded, toggled, toggled, toggled, verified that data are saved.
Reloaded.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4812
Summary: Add a field where you can put the gravatar email address to pull an image for the profile picture from
Test Plan: Tried uploading a file, replacing with default, and various combinations and they all still work.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T2105
Differential Revision: https://secure.phabricator.com/D4809
Summary: Remove css class that was setting static width
Test Plan: Loaded user profile edit page, stretched browser around, saw that the text was happy
Reviewers: epriestley, btrahan
Reviewed By: btrahan
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4806
Summary:
We are doing a better job in 1) of D3069#3 and 2) is just dumb.
Let's see if someone notices this change.
Test Plan: /settings/panel/display/
Reviewers: nh, epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4789
Test Plan: Ran the migration on a single revision, verified DB, called `loadUnsubscribedPHIDs()`.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4786
Summary: Suggest the MySQL mode STRICT_ALL_TABLES during setup if it is not set. Small improvement to the phabricator.developer-mode comments.
Test Plan: Set the global sql_mode to include or exclude STRICT_ALL_TABLES and check for desired behavior.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4803
Summary:
Make `PhabricatorMenuView` more flexible, so callers can add items to the beginning/end/middle.
In particular, this allows event handlers to receive a $menu and call `addMenuItemToLabel('activity', ...)` or similar, for D4708.
Test Plan: Unit tests. Browsed site. Home page, Conpherence, and other pages with menus look correct.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D4792
Summary:
By default, order applications in application order. See discussion in D4708.
Principally, this is intended to make sure that application event handlers are registered in order, and thus fire in order.
Test Plan:
Looked at /applications/, homepage tiles, verified they both still work.
I didn't actually test the event handler bit since it's fairly complicated to test blind; D4708 should provide a test case.
Reviewers: btrahan, Afaque_Hussain
Reviewed By: Afaque_Hussain
CC: aran
Differential Revision: https://secure.phabricator.com/D4791
Summary: Regression to original behavior.
Test Plan: Clicked on it twice, didn't see confirmation dialog.
Reviewers: epriestley, codeblock
Reviewed By: codeblock
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4788
Summary: Applied fixes for issues mentioned in D4737#1&2
Test Plan: Verified that scripts seem to work as intended.
Reviewers: epriestley
CC: aran, Korvin
Maniphest Tasks: T2446
Differential Revision: https://secure.phabricator.com/D4782
Summary:
Try to lock the screen to whatever the user is looking at as we load changesets.
Notably, this improves the use case of taking a known action on a diff. Currently, you have to wait for everything to load or the comments keep getting scrolled down. After this change, the comments stay in the same place on screen.
Test Plan:
Raised the autoload changeset limit from 100 to 1000, looked at a 220 changeset diff.
- Reloaded it while scrolled at the top; normal behavior (no scrolling).
- Reloaded it, scrolled to the bottom. Comment area now stable.
- Reloaded it, kind of scrolled around the middle? Behavior seemed stable/reasonable. This one is kind of heursitic so it's hard to say I'm getting it totally right or not, but it's less important than the "bottom" case.
Reviewers: vrana, btrahan, chad, dctrwatson
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D4774
Summary: Refactor options related to verbose error reporting and forcing disk reads into a single developer option.
Test Plan: Run Phabricator with the developer-mode option set and check that errors print stack traces, static assets are always reloaded, etc.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D4780
