I'm currently thinking about making this configuration push-based instead of pull-based: each server is told about other servers it should publish to when it starts up. When it receives a notification, it publishes to all those servers (with reasonable mechanisms in place to prevent cycles).
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 13 2016
This report doesn't have reproduction instructions (see Providing Reproduction Steps) and is likely obsoleted by T10697.
- D15695 should fix logged-out users.
- D15696 + D15697 should smooth out security.require-https for intracluster requests.
There's an overview of a different third-generation endpoint, owners.search, here:
It's available on maniphest.search.
Given current progress and velocity, I'm aiming for a timeline roughly like this:
I've started moving these changes into production (T10784) so I can begin gathering confidence that they actually work. The repository stuff definitely still doesn't work since several core pieces are currently implemented as // TODO comments, but it has the synchronization bookkeeping in place for all the locking/versioning: if that's stable, it will give me confidence that we're on relatively firm ground and can move forward.
This should be resolved at HEAD of master; updating Phabricator should restore things to working order.
I happen to know this one offhand.
Quoting and signature stripping works properly in major clients -- you can find the implementation here:
This is the same as T4181, sort of, except that merged somewhere else and isn't the same as itself, if you will.
Maybe T8646 is a closer match? Dupe of one or the other in any case, I think.
Apr 12 2016
Ah, yep, thanks.
This sort of works now. The 002 node is live, just not reachable yet. Some weird stuff I hit:
I'm probably going to break all repositories momentarily. If I do, I'll try to fix them.
Very minor technical note: we can't support this for all providers. The username + password, LDAP, and I think Persona (although see T10125) providers can't initiate a login flow with a redirect (since the user has to type stuff or do javascriptey things, not just navigate to a URI).
sure.
That feature exists, but it's currently only supported for the Phabricator provider. There's no technical reason we can't support it on other providers, it was just built very narrowly for a Phacility (SAAS) use case and it was simpler to keep it narrowly scoped:
Some additional cases with this:
and assigned to seems to be an essential information
Apr 11 2016
This request does not describe a root problem; instead, it asks for a specific feature. See Describing Root Problems for help.
Progress so far:
Looks like D15680 worked.
T6996 is adjacent.
This report does not appear to describe a bug in Phabricator, and does not include version information or reproduction steps.
Apr 10 2016
I'm probably done for the night, here's a quick update:
Apr 9 2016
We need this for T4571 for the cluster status console so it doesn't take 10000 years if replicas are down.
Yeah, that should work fine. To promote, you'd update the VIP stuff and Phabricator could remain in the dark.
I think the answer is yes:
I think this is fine to close for now -- the discussion probably remains relevant going forward, but I can point back here the next time a driving use case arises. I think we're unlikely to pursue any of this "suggest a patch" vein of changes on our natural roadmap for a long time.
This is now deployed and appears to be working.