One inline thing, but the rest of this looks correct as far as I can tell.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 20 2019
Rename some variables for clarity.
- Renamed classes to remove Configuration
- Created PhabricatorApplicationTransactionJSONDiffDetailView to reduce JSON-related boilerplate
- Found one callsite to switch to PhabricatorApplicationTransactionJSONDiffDetailView
- Implemented getTitle for the various JSON-encoded transactions
- Requested fixes
I have a patch for this which basically says "don't try to kill any process which doesn't look like a daemon process".
No wonder I couldn't pass the Facebook eng interview!!
We've run instances in the Phacility cluster for a long time now, but this is generally not something we really support or plan to support since there's no real customer interest in instancing Phabricator.
Builds have a hard dependency on D20597.
The power is in my hands, now.
But wait! It says there are two ways! The other way is:
If you are just writing an upstart job that needs to start the service after the basic facilities are up, either of these will work:
start on (local-filesystems and net-device-up IFACE!=lo)
This was effectively resolved in 2019 Week 17 (Very Late April). Now, only ancestors of "Permanent Refs" trigger any publishing behavior (audits, notifications, feed, etc).
This is very old and it doesn't look like we ever found a working set of reproduction steps.
To avoid the extreme case of ComComComJava-itis we could maybe just drop the word Configuration from these classes?
To avoid the extreme case of ComComComJava-itis we could maybe just drop the word Configuration from these classes? No other type of EditEngine ... Transaction is ever likely to exist or make sense.
Jun 19 2019
the (Show Details) would be a great first step for us - and cover our needs. Much like the logs for Herald Rules and other areas.
🐫 Does this button work ------>>^^^
There are a few pieces here, since we have to thread the needle through many layers to get where we want to go.
If JIRA links are mostly/all in the form ?page=com.jira.jira.plugin.extension.gateway-to-realms-of-wonder&exec=rm -rf / that might also mean that "links which don't really link to the task" are common and that "task + params" is more like "portal to arbitrary plugin behavior", although I'm not having much luck digging up more information about this by Googling.
(Also, now that I've read PHI1312, I mind this^^ implementation less since that was the actual support request anyway).
In D20592#260267, @epriestley wrote:Do you think ( XXX-123 Order More Copier Paper ) is still a reasonable rendering if the parameter is something like ?download=123 and that means "Download Attached File 123" and clicking the link doesn't take you to XXX-123 at all?
Also, practically, I can't actually figure out how to get either modern JIRA or Asana to generate any URI with any parameters or fragments at all. Neither appears to support linking directly to a comment.
I guess my assumption is that ?a=b may, in the general case, completely change the meaning of the link. Although I think this has mostly been purged from the web now, an example was #! fragments before the widespread use of the history API, where https://example.com/a/#!b actually meant "Page B", not "Page A", and labeling the link "Page A" would be misleading.
If it's the same thing, that seems possibly confusing (two different links have the same visual rendering).
It's meaningfully more work, but the bigger thing stopping me is that I'm not sure what the best display behavior is.
This is just short-circuiting the whole external object lookup process, right? Is it significantly more work to just fix the lookup process to preserve these fragments?
See also T13317.
👻
See PHI1312. The modified JIRA rules reportedly misfire on URIs with anchors or parameters. For now, the plan is to just skip these URIs. In the future, we might specialize URIs which (for example) link to comments on foreign objects.
I'm going to close this in favor of T13291. Referencing files by full URI currently works, and relative references and other behavior is planned.
Getting rid of the indirect writes on handle reads would probably be nice eventually, but doesn't directly accomplish anything today.
I think that might be everything? Not entirely sure, but haven't seen any more since the last deploy.
D20573 has one issue where the "Select" buttons in the "Merge Duplicates In" dialog are now closing the dialog. We might be missing a JX.pass() / e.prevent() (hopefully) or might need to get slightly more creative in distinguishing between navigation links and javascript magic links.
Jun 18 2019
Yeah, there's a lot of very ambiguous behavior here in the face of ambiguous inputs. I think we're probably not walking into too much of a minefield, but I'm not confident I picked the best behavior for all malformed/suspicious inputs.
I'm a little worried about a Postel's Law-style HTML parser. Later on I can envision getting more strict about what we accept in the interest of delivering more precise error messages, which might break existing pages that previously worked just by accident. I guess if it ever comes to that, we can write a migration that warns installs about suddenly-malformed wiki pages.