Summary:
Ref T11522. This tries to reduce the cost of rewriting a repository by making handles smarter about rewritten commits.
When a handle references an unreachable commit, try to load a rewrite hint for the commit. If we find one, change the handle name to "OldHash > NewHash" to provide a strong hint that the commit was rewritten and that copy/pasting the old hash (say, to the CLI) won't work.
I think this notation isn't totally self-evident, but users can click it to see the big error message on the page, and it's at least obvious that something weird is going on, which I think is the important part.
Some possible future work:
- Not sure this ("Recycling Symbol") is the best symbol? Seems sort of reasonable but mabye there's a better one.
- Putting this information directly on the hovercard could help explain what this means.
Test Plan: {F1780719}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11522
Differential Revision: https://secure.phabricator.com/D16437
Summary:
Ref T11522. When a commit is no longer reachable from any branch/tag, we currently show a "this has been deleted" message.
Instead, go further: check if there is a "rewritten" hint pointing at a commit the current commit was rewritten into. If we find one, show a message about that instead.
(This isn't super pretty, just getting it working for now. I expect to revisit this UI in T9713 if we don't get to it before that.)
Test Plan: {F1780703}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11522
Differential Revision: https://secure.phabricator.com/D16436
Summary: Ref T11522. This migrates any "badcommit" data (which probably only exists at Facebook and on 1-2 other installs in the wild) to the new "hint" table.
Test Plan:
- Wrote some bad commit annotations to the badcommit table.
- Viewed them in the web UI and used `bin/repository reparse --change ...` to reparse them. Saw "this is bad" messages.
- Ran migration, verified that valid "badcommit" rows were successfully migrated to become "hint" rows.
- Viewed the new web UI and re-parsed the change, saw "unreadable commit" messages.
- Viewed a good commit; reparsed a good commit.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11522
Differential Revision: https://secure.phabricator.com/D16435
Summary:
Ref T11522. This provides storage for tracking rewritten commits (new feature) and unreadable commits (existing feature, but really hacky).
This doesn't do anything yet, just adds a table and a CLI tool for updating it. I'll document the tool once it works. You just pipe in some JSON, but I need to document the format.
Test Plan:
- Piped JSON for "none", "rewritten" and "unreadable" hints into `bin/repository hint`.
- Examined the database to see that the table was written properly.
- Tried to pipe bad JSON in, invalid hint types, etc. Got reasonable human-readable error messages.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11522
Differential Revision: https://secure.phabricator.com/D16434
Summary: Getting rid of some code! This method has no callsites so it should be safe to remove completely. Ref T9690
Test Plan: Removed method and clicked around to make sure nothing broke.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: yelirekim, epriestley
Maniphest Tasks: T9690
Differential Revision: https://secure.phabricator.com/D16439
Summary: Adds a schema patch that removes conduit_connectionlog. This table hasn't been used in 8ish months so it's probably safe to get rid of.
Test Plan: Apply the patch locally and confirm that the table does indeed get dropped.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley
Differential Revision: https://secure.phabricator.com/D16438
Summary: Removed call to the deprecated buildStandardPageResponse method from XHProfProfileController
Test Plan: Install, configure, and use XHProf. I'll need some guidance with this
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin, epriestley
Differential Revision: https://secure.phabricator.com/D16432
Summary:
After D16431, listing the same `@annotation` multiple times makes the docblock parser return a list.
We have some resources which list `@requires` or `@provides` several times, but don't handle the new parser properly. Make the code more flexible, since this is a reasonable way to specify the annotations.
See also D16432. This produces a failure in this form:
```
[2016-08-23 21:10:15] ERROR 2: trim() expects parameter 1 to be string, array given at [/core/data/drydock/workingcopy-74/repo/phabricator/src/applications/celerity/CelerityResourceMapGenerator.php:236]
2 arcanist(head=master, ref.master=89e8b4852384), phabricator(head=6c940fb71b0a8850c6a1b7f5fc642a8f8135a76a, ref.master=b521f2349e46), phutil(head=master, ref.master=237549280f08)
3 #0 trim(array) called at [<phabricator>/src/applications/celerity/CelerityResourceMapGenerator.php:236]
4 #1 CelerityResourceMapGenerator::getProvidesAndRequires(string, string) called at [<phabricator>/src/applications/celerity/CelerityResourceMapGenerator.php:193]
5 #2 CelerityResourceMapGenerator::rebuildTextResources(CelerityPhabricatorResources, CelerityResourceTransformer) called at [<phabricator>/src/applications/celerity/CelerityResourceMapGenerator.php:54]
6 #3 CelerityResourceMapGenerator::generate() called at [<phabricator>/src/__tests__/PhabricatorCelerityTestCase.php:16]
7 #4 PhabricatorCelerityTestCase::testCelerityMaps()
8 #5 call_user_func_array(array, array) called at [<arcanist>/src/unit/engine/phutil/PhutilTestCase.php:492]
9 #6 PhutilTestCase::run() called at [<arcanist>/src/unit/engine/PhutilUnitTestEngine.php:69]
10 #7 PhutilUnitTestEngine::run() called at [<arcanist>/src/unit/engine/ArcanistConfigurationDrivenUnitTestEngine.php:147]
11 #8 ArcanistConfigurationDrivenUnitTestEngine::run() called at [<arcanist>/src/workflow/ArcanistUnitWorkflow.php:167]
12 #9 ArcanistUnitWorkflow::run() called at [<arcanist>/scripts/arcanist.php:394]
```
Test Plan: Ran `bin/celerity map`, no more warnings and no change to the actual map.
Reviewers: joshuaspence, chad
Reviewed By: chad
Differential Revision: https://secure.phabricator.com/D16433
Summary: Added a brand new shiny cat fact
Test Plan: Pulled up a project with motivator installed and nothing broke
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin, epriestley
Differential Revision: https://secure.phabricator.com/D16430
Summary: Switches over to new property UI boxes, splits core and apps into separate pages. Move Versions into "All Settings". I think there is some docs I likely need to update here as well.
Test Plan: Click on each item in the sidebar, see new headers.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D16429
Summary:
Ref T7148. The automated export process runs this via daemon, which can't answer "Y" to this prompt. Let it "--force" instead.
(Some of my test instances didn't have any repositories, which is why I didn't catch this sooner.)
Test Plan: Ran `bin/repository move-paths --force ...`, saw change applied without a prompt.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T7148
Differential Revision: https://secure.phabricator.com/D16426
Summary: Ref T11132. Will work on CSS tomorrow, but wanted to rough in the UI Steps to get guidance. Not sure what you have in mind for the "app" part, if you want to explain it and I build or you build.
Test Plan: Visit each page and click on links. Very rough and unfinished.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Maniphest Tasks: T11132
Differential Revision: https://secure.phabricator.com/D16419
Summary: Ref T11132. Adds a background color option to PHUIIconView, for use whereever, and NUX. Also normalize icon placement for mixed image/icon result list.
Test Plan: Test in UIExamples, and Global Settings.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Maniphest Tasks: T11132
Differential Revision: https://secure.phabricator.com/D16424
Summary: Fixes T11493. This code is a little bit weird/clever, simplify it so that we always cast the handles to an array early on.
Test Plan: {F1767668}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11493
Differential Revision: https://secure.phabricator.com/D16422
Summary: Fixes T11501. Let's you pass in a full PHUIIconView or just the icon name to give ObjectListItem a large icon.
Test Plan: Alamanac, Applications, Drydock, Settings, Search Typeahead, Config page...
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin, PHID-OPKG-gm6ozazyms6q6i22gyam
Maniphest Tasks: T11501
Differential Revision: https://secure.phabricator.com/D16421
Summary: I don't think we use footicons, removing that CSS. States were added but only used in Auth, convert them to statusIcon instead.
Test Plan: Visit Auth, UIExamples, grep for `setState`
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D16418
Summary: Ref T11132, Ref T11478. Builds out a basic PHUICMSView and Guides Application, no content / modules.
Test Plan: Go to /guides/, see blank states for new guides.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Maniphest Tasks: T11132, T11478
Differential Revision: https://secure.phabricator.com/D16414
Summary:
Fixes T11488. I broke this in D16360, I think by doing a little extra refactoring after testing it.
This code is very old, before commits always needed to have repositories attached in order to do policy checks.
Modernize it by mostly just using the repository which is present on the Commit object, and using the existing edge cache.
Test Plan: Ran a commit through the Herald test adapter.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11488
Differential Revision: https://secure.phabricator.com/D16413
Summary:
Fixes T11480. This cleans up the error logs a little by quieting three common errors which are really malformed requests:
- The CSRF error happens when bots hit anything which does write checks.
- The "wrong cookie domain" errors happen when bots try to use the `security.alternate-file-domain` to browse stuff like `/auth/start/`.
- The "no phcid" errors happen when bots try to go through the login flow.
All of these are clearly communicated to human users, commonly encountered by bots, and not useful to log.
I collapsed the `CSRFException` type into a standard malformed request exception, since nothing catches it and I can't really come up with a reason why anything would ever care.
Test Plan:
Hit each error through some level of `curl -H ...` and/or fakery. Verified that they showed to users before/after, but no longer log.
Hit some other real errors, verified that they log.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11480
Differential Revision: https://secure.phabricator.com/D16402
Summary: This needs an `isset()` for cases when authority and packages don't completely overlap.
Test Plan:
- With a package set to trigger autoreview, created a revision.
- Observed error log, saw no more error.
- Saw package trigger autoreview properly.
Reviewers: chad
Reviewed By: chad
Differential Revision: https://secure.phabricator.com/D16398
Summary:
Ref T11473. If you write a method like `get_stuff(ids)` and then call it with an empty list of IDs, you can end up passing an empty constraint to Conduit.
If you run a `*.search` method with such a constraint, like this one:
```
{
"ids": []
}
```
...we have three possible beahviors:
# Treat it like the user passed no constraint (basically, ignore the constraint).
# Respect the constraint (return no results).
# Error.
Currently, we do (1). However, this is pretty confusing and I think clearly the worst option, since it means `get_stuff(array())` in client code will often tend to return a ton of results.
We could do (2) instead, but this is also sort of confusing (it may not be obvious why nothing matched, even though it's an application bug) and I think most reasonable client code should be doing an `if ($ids)` test: this test makes clients a little more complicated, but they can save a network call, and I think they often need to do this test anyway (for example, to show the user a different message).
This implements (3), and just considers these to be errors: this is the least tricky behavior, it's consistent with what we do in PHP, makes fairly good sense, and the only cost for this is that client code may need to be slightly more complex, but this slightly more complex code is usually better code.
Test Plan: Ran Conduit `*.search` queries with `"ids":[]` and `"phids":[]`, got sensible errors instead of runaway result sets.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11473
Differential Revision: https://secure.phabricator.com/D16396
Summary:
Ref T11473. When running `harbormaster.build.search` with a `buildables` constraint, the constraint doesn't get passed to the Query and so currently has no effect.
This piece of logic was just accidentally omitted from D16356. It is probably not used anywhere today and doesn't show up in the UI, so it's easy to overlook (I missed it in review, too).
Test Plan: Ran `harbormaster.build.search` with a `buildables` constraint, got expected filtering.
Reviewers: yelirekim, chad
Reviewed By: chad
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
Maniphest Tasks: T11473
Differential Revision: https://secure.phabricator.com/D16395
Summary:
When I wrote this the first time, only hosted repositories could be clustered.
This check wasn't removed when I allowed observed repositories to be clustered in D15986.
Test Plan:
Reloaded {nav Config > Repository Servers} page, saw more stuff locally.
Reviewed the cardinal digits between 1 and 17, inclusive.
Reviewers: chad, avivey
Reviewed By: avivey
Differential Revision: https://secure.phabricator.com/D16392
Summary:
I converted this call incorrectly in D16092. We should pass the `PhutilURI` object, not the string version of it.
Specifically, this resulted in hitting an error like this if a replica needed synchronization:
```
[2016-08-11 21:22:37] EXCEPTION: (InvalidArgumentException) Argument 1 passed to DiffusionCommandEngine::setURI() must be an instance of PhutilURI, string given, called in...
#0 PhutilErrorHandler::handleError(integer, string, string, integer, array) called at [<phabricator>/src/applications/diffusion/protocol/DiffusionCommandEngine.php:52]
#1 DiffusionCommandEngine::setURI(string) called at [<phabricator>/src/applications/diffusion/protocol/DiffusionRepositoryClusterEngine.php:601]
...
```
Test Plan: Clusterized an observed repository, demoted a node, ran `bin/repository update Rxxx` to update, saw no typehint fatal.
Reviewers: chad
Reviewed By: chad
Differential Revision: https://secure.phabricator.com/D16390
Summary:
Fixes T11453. Currently, commit message summaries are limited to 80 bytes. This may only be 20-40 characters for CJK languages or langauges with Cyrillic script.
Increase storage size to 255, then truncate to the shorter of 255 bytes or 80 glyphs. This preserves the same behavior for latin languages, but is less tight for Russian, etc.
Some minor additional changes:
- Provide a way to ask "how much data fits in this column?" so we don't have to duplicate column lengths across summary checks or UI errors like "title too long".
- Remove the `text80` datatype, since no other columns use it and we have no use cases (or likely use cases) for it.
Test Plan:
- Made a commit with a Cyrillic title, saw reasonable summarization in UI:
{F1757522}
- Added and ran unit tests.
- Grepped for removed `SUMMARY_MAX_LENGTH` constant.
- Grepped for removed `text80` data type.
Reviewers: avivey, chad
Reviewed By: avivey
Subscribers: avivey
Maniphest Tasks: T11453
Differential Revision: https://secure.phabricator.com/D16385
Summary: Fixes T9410. Depends on D16382. Since all users can now view all Herald rules, we can link them in the transcripts.
Test Plan: Viewed a transcript, clicked rule names, reviewed rules.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9410
Differential Revision: https://secure.phabricator.com/D16383
Summary:
Ref T9410. This changes the view policy for all Herald rules to the most public policy ("All Users" for private installs, "Public" for public installs).
See T11428 for discussion of this change in greater detail. In practice, this is //approximately// how things work today anyway, since you can almost always see almost all of this information in transcripts.
I believe this narrower view policy is helpful in zero cases and slightly confusing or harmful in a number of reasonable cases.
Test Plan: Viewed personal, object and global rules as users who could and could not edit the rules.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9410
Differential Revision: https://secure.phabricator.com/D16382
Summary: Converts final call site to PHUIDocumentViewPro.
Test Plan: grep for PHUIDocumentView, view new Welcome Page
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D16379
Summary: Fixes T11437. Provides a normal form for configuring this, instead of weird "look up the PHID and adjust things in the database" stuff.
Test Plan:
{F1753651}
{F1753652}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11437
Differential Revision: https://secure.phabricator.com/D16377
Summary:
This updates the eye logo and removes the formal wordmark "Phabricator" as an image. Instead we'll use the new updated eye logo and plain text for "Phabricator", both of which are more friendly and less industrial.
Installs that already use the `header-logo` customization setting will need to rebuild their logo to 80px x 80px. They will then also get to use plain text to whitebox their install as they see fit.
Test Plan:
Tested new logo at desktop, tablet, and mobile sizes. Set a random instance name, saw new wordmark. Created a really long wordmark of MMMMMMMMMMMM, saw text cut off so UI doesn't break. May need some additional tweaking, but I think we covered the most edge cases here.
{F1751791, size=full}
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: edibiase, bjshively, yelirekim, Korvin
Maniphest Tasks: T4214, T11096
Differential Revision: https://secure.phabricator.com/D16373
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
Summary: I find this fact very useful for understanding my feline companion
Test Plan: Added "Motivator: Cat Facts" to the project, nothing broke
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley
Differential Revision: https://secure.phabricator.com/D16374
Summary: Makes sidenav disappear again on projects/profiles, but shows it on home again (tablet views).
Test Plan: Visit Profile/Projects/Home on mobile, desktop, and tablet. See nav disappear correctly.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D16369
Summary: Fixes T11420. These are selected in newest-to-oldest order from the database, but we should show them in oldest-to-newest order in the UI.
Test Plan:
Tagged a couple tasks with "A, B, C" projects, saw correct order in UI:
{F1749351}
{F1749352}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11420
Differential Revision: https://secure.phabricator.com/D16367
Summary:
Fixes T9719. Currently, the Herald "Test Console" has a big `instanceof` thing, so new adapters (like a Calendar adapter, or third-party adapters) aren't available automatically. Instead, do a standard modular thing: load the available adapters, ask which ones can test the object the user selected, then let the user pick which one they want to move forward with.
Additionally, it isn't very clear that you can't test "commit hook" rules because they rely on push state which we don't really have a good way to simulate. When the user picks a commit, we now show them the "Hook" events, but the options are disabled and explain why they can not be selected.
Test Plan:
- Ran test rules for revisions, commits, mocks, tasks, wiki documents, questions, and outbound mail.
- Plugged in a commit, got a more-helpful choice screen explaining why you do a test run of hook rules.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T9719
Differential Revision: https://secure.phabricator.com/D16360
phpexcel.net currently serves a 500 page, and the top Google hit for
PHPExcel (on codeplex) gives you a site warning you that it is 3 years
out of date, and to see GitHub instead.
Update the link from Maniphest's 'please install PHPExcel to enable
export' prompt.
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
Summary: Fixes T11409. This syntax isn't compatible with older PHP.
Test Plan: Ran `arc lint` on the file.
Reviewers: yelirekim, chad
Reviewed By: chad
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
Maniphest Tasks: T11409
Differential Revision: https://secure.phabricator.com/D16358
Summary: We deprecate the existing API method used to access build information from the API, but preserve its response structure after calling through to the new method. I've cordoned off the fields I needed to define in order to meet the output structure by putting those fields in a search attachment.
Test Plan:
Used the API console and looked at the list view controller for builds.
Old output structure:
```lang=json
{
"data": [
{
"id": "16823",
"phid": "PHID-HMBD-xghrwfz6luoye5rgc2hq",
"uri": "https://secure.phabricator.com/harbormaster/build/16823/",
"name": "Run Core Tests",
"buildablePHID": "PHID-HMBB-s6ykzm2jzxz4ymduztq3",
"buildPlanPHID": "PHID-HMCP-pcfxcgyoif67l3buc4zt",
"buildStatus": "passed",
"buildStatusName": "Passed"
}
],
"cursor": {
"limit": 100,
"after": "16823",
"before": null
}
}
```
New output structure:
```lang=json
{
"data": [
{
"id": 1,
"type": "HMBD",
"phid": "PHID-HMBD-qpgcmv67tzaauzayzit5",
"uri": "http://ec2-54-165-244-168.compute-1.amazonaws.com/harbormaster/build/1/",
"name": "arc lint + arc unit",
"buildStatusName": "Passed",
"buildablePHID": "PHID-HMBB-qdefith5uakkepqpjr2g",
"buildPlanPHID": "PHID-HMCP-zswbhazb7ipmaf4plygg",
"buildStatus": "passed",
"initiatorPHID": "PHID-USER-rihx4366f3aczsvc2wtb",
"dateCreated": 1450295643,
"dateModified": 1450295644,
"policy": {
"view": "users",
"edit": "users"
}
}
],
"maps": {},
"query": {
"queryKey": null
},
"cursor": {
"limit": 100,
"after": null,
"before": null,
"order": null
}
}
```
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin, epriestley
Differential Revision: https://secure.phabricator.com/D16356
Summary:
It's only natural for users to be interested their own builds. We are also building in support for other sources of builds, the only formally supported way to run a build right now is via Herald.
In our third party codebase, we designate an application as the "thing" that started builds which are scheduled and managed automatically by phabricator. I believe this is a common practice elsewhere in the codebase when you're at a loss for a real human identity and you need to apply some transactions.
Test Plan: Ran some builds manually and saw them show up under the list of things I've run. Looking up builds based on those that had been started by a herald rule.
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin, epriestley
Differential Revision: https://secure.phabricator.com/D16353
Summary:
Ref T11404. Depends on D16351. Currently, both `differential.query` and `differential.revision.search` issue `2N` queries to fetch:
- dependencies for each revision; and
- projects for each revision.
Fix this:
- Take these custom fields out of Conduit so they don't load this data by default.
- For `differential.query`, put this data back in by hard coding it.
- For `differential.revision.search`, just leave it out. You can already optionally get projects efficiently, and this endpoint is a work in progress. I would tentatively be inclined to expose graph data as a "graph" extension once we need it.
This makes both methods execute in `O(1)` time (which is still 20-30 queries, but at least it's not 320 queries anymore).
Test Plan:
- Ran `differential.query`, observed no change in results but 199 fewer internal queries.
- Ran `differential.revision.search`, observed data gone from results and 200 fewer internal queries.
Reviewers: yelirekim, chad
Reviewed By: chad
Maniphest Tasks: T11404
Differential Revision: https://secure.phabricator.com/D16352
Summary:
Ref T11404. Depends on D16350.
Currently, custom fields can issue "N+1" queries in some cases, so querying 100 revisions issues 100 extra queries.
This affects all `*.search` endpoints for objects with custom fields, and some older endpoints (notably `differential.query`).
This change bulk loads "normal" custom fields, which gets rid of some of these queries. Instead of loading fields for each object, we build a big list of all fields and load them all at once.
The next change will tackle the remaining inefficient edge queries.
Test Plan:
- Configured a custom field with normal database storage in Differential.
- Ran `differential.query`, looking at custom fields in results for correctness.
- Ran `differential.revision.search`, looking at custom fields in results for correctness.
- In both cases, observed queries drop from `3N` to `2N` (all the "normal" custom field stuff got bulk loaded).
Reviewers: yelirekim, chad
Reviewed By: chad
Maniphest Tasks: T11404
Differential Revision: https://secure.phabricator.com/D16351
Summary:
Ref T11404. Currently, SearchEngineAttachments can bulk-load data but SearchEngineExtensions can not.
This leads to poor performance of custom fields. See T11404 for discussion.
This changes the API to support a bulk load + format pattern like the one Attachments use. The next change will use it to bulk-load custom field data.
Test Plan:
- Ran `differential.query`, `differential.revision.search` as a sanity check.
- No behavioral changes are expected
- See next revision.
Reviewers: yelirekim, chad
Reviewed By: chad
Maniphest Tasks: T11404
Differential Revision: https://secure.phabricator.com/D16350
Summary:
We're picking three useful groups of build statuses to provide as default queries:
- Stuff not yet building
- Stuff building
- Stuff which has finished building
These are reasonable buckets for builds since (unlike most objects in phabricatorland) users are generally waiting impatiently for the machine to do something for them, rather than being responsible for doing something with the machine.
Test Plan: clicked around the search engine and enjoyed my defaults
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley
Differential Revision: https://secure.phabricator.com/D16349
Summary:
This supports a few basic use cases that aren't served by the buildable search engine:
- I'm trying to discover when the last time that this particular build plan failed was.
- I want to know if any builds have deadlocked.
- At a glance, I'm more interested in what build plans are running, not which buildables are being built. This is more often than not the case.
Test Plan: {F1744003}
Reviewers: epriestley, #blessed_reviewers
Reviewed By: epriestley, #blessed_reviewers
Subscribers: Korvin, epriestley
Differential Revision: https://secure.phabricator.com/D16347
Summary:
Ref T4788. This gives us a new level of graceful degradation, so now we show:
- Zero through 100 connected tasks: whole graph.
- More than 100 connnected tasks, but fewer than 100 direct parents/subtasks: just parents and subtasks, with "..." to hint that the graph is cut off.
- More than 100 parents and children: just the "sorry, too much stuff" error message.
Test Plan: {F1740882}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4788
Differential Revision: https://secure.phabricator.com/D16344
Summary:
Ref T4788. Add links to jump to search results with a task's parents or subtasks. This allows relationships to remain useful if there are a zillion of them, and you can sort/filter stuff more easily.
Language might need some tweaking at some point, feeling a little un-brainy today with wordstuff.
Test Plan:
{F1740855}
{F1740856}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4788
Differential Revision: https://secure.phabricator.com/D16343
Summary:
Ref T8126. Ref T4788. This adds a way to query by parent or subtask.
I plan to link to this from the task graph (e.g., {nav View > Search Subtasks} or similar, in a dropdown on the "Task Graph" element) as a way to let us bail out if tasks have 300 subtasks and send the user to a big query result list. That'll give us more flexibility to tailor the UI for reasonable numbers of tasks.
There's no UI for this unless you specify a query yourself, so the only ways to get to it are:
- Manually put `?parentIDs=...` into the URI.
- Use the API.
- Future link from task graphs.
It doesn't seem too useful to me on its own, outside of the context of links from tasks.
Test Plan:
- Manually put `?parentIDs=...` and `?subtaskIDs=...` into Maniphest query UI, got expected results.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T4788, T8126
Differential Revision: https://secure.phabricator.com/D16341
Summary:
Ref T8126. See that task for discussion. This change:
- Updates language to be more consistent ("Parents", "Subtasks") since I moved us away from the often-confusing "Block" language in T4788.
- Fixes bugs with finding the wrong set of tasks if tasks have a mixture of open and closed subtasks or parents.
Test Plan:
- Created four tasks: no subtasks, one closed subtask, one open subtask, mixture of open and closed subtasks.
- Created four more tasks: no parents, one closed parent, one open parent, mixture of open and closed parents.
- Searched for all this stuff, got the proper results:
{F1740683}
{F1740684}
{F1740685}
{F1740686}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T8126
Differential Revision: https://secure.phabricator.com/D16340
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
Summary: Ref T8116. Puts a list of packages on the publisher page, and a list of versions on the package page.
Test Plan: Viewed a publisher, saw packages. Viewed a package, saw versions. Looked at list views.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T8116
Differential Revision: https://secure.phabricator.com/D16321
Summary: Ref T8116. Add search-by-name and per-package / per-publisher search to Packages.
Test Plan: Searched publishers, packages, versions by name. Searched packages by publisher. Searched versions by package.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T8116
Differential Revision: https://secure.phabricator.com/D16320
Summary:
Ref T8116. This adds a control for creating publishers (default: administrators) and default publisher/package edit controls.
I've left the edit defaults at "no one" for now to force you to select a policy. This might be something to look at later.
Test Plan: Created publishers, packages. Tried to create publishers with "can create" policy set restrictively.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T8116
Differential Revision: https://secure.phabricator.com/D16319
Summary:
Ref T8116. A version has:
- a package (like "Arcanist") which it belongs to;
- a name (like "v3.1.5").
The name is immutable and unique, like the package key and publisher key.
Policy stuff:
- Versions have the exact same policies as their packages.
- You must be able to edit a package to create new versions of it.
This is still entirely uninteresting.
Test Plan: {F1731703}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T8116
Differential Revision: https://secure.phabricator.com/D16316
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
