So should Arcanist be modified to just call differential.revision.edit directly then?

From D17067:

As I mentioned over email, you'll have to update Phabricator before asking for help. That version looks at least 18-24 months old and there have been significant changes.

thanks

Please read Support Resources for where we take questions about Phabricator. This doesn't appear to be a feature request.

FWIW #Twitter has multiple users of this feature and we'd likely get complaints if it broke

You have installed multiple versions of PHP, some of which have cURL and some of which do not.

Huh, when I run that, it shows PHP Version => 7.1.0. Why would this be different? I even uninstalled php7 from my computer.

How about this?

It returns "YES"

Okay, how about this?

Here:

Can you show us the output of this command?

Thanks for these suggestions. We only had one CI machine so these kinds of concerns about parallelism are not important for us. I enabled the options that you suggested.

I do use it, but not in conjunction with preview.

Oh, there's no preference for this right now. I'll probably just keep "Z" for the moment.

We haven't received more information about this in about a week and can't reproduce it, so we can't move forward. I'm going to close this until we get new information.

I'm going to merge this into T10517 which discusses making build variables extensible. See that task for some more discussion of similar issues.

Yes, this is consistent with running bin/storage upgrade from master, then switching to stable.

From a cursory read of CVE-2016-10045, it seems like PHP may be written in such a way that mail() can not be invoked safely. Silly PHP!

updated advisory; https://legalhackers.com/advisories/PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10045-Vuln-Patch-Bypass.html
I don't think this changes the plan you suggest, just linking for completeness.

@epriestley Yes I need to make changes, I didn't say it is impossible.

Cool, thanks!

T10855 talks about being able to update dashboard panels with content (which you install). T8145 covers broadcasting alerts, T8629 covers getting users alerted to individual things, M1473 covers upcoming changes to home/dashboards which will allow admins to globally install items onto home.

If this was available as a variable, wouldn't you have to make all those changes to Harbormaster build plans anyway? Why is it impossible to change the plans to use a constant, but possible to change them to use a variable?

@epriestley In our current usage, we used a lot of herald rules that points to multiple harbormaster for building differential and commits.

Why does this need to be a variable? That is, why can't you just hard-code the value in place of having a variable?

Offhand, It seems your database is on master, and code is on stable.

This appears to be the fix:

Note that there is a Sender-related RCE in PHPMailer until Dec 2016, see T12046 for discussion.

Although this wording is a little unclear, commandeering makes you the author. A more precise wording would be something like "The current author for this revision is X. It was created on Y." but that's clunky and only smooths out this particular case.

ah, found it. My fault before was, that I only digged into DB phabricator_auth, but i found it now at phabricator_user, table phabricator_session.

No idea, where have you looked so far?

In which table can I find them?

Can you show us the output of these commands?

Delete them from the database.

I have no idea how to reproduce this error. I'd guess something along the lines of take a new version of Phabricator and apply an old upgrade script, but that's really just a guess.

See some discussion starting here:

Yes. I think we had a similar element at some point, but removed it in a design update some time ago because it felt visually busy/redundant, particularly across other object types. If you do a lot of copy/pasting into Google Docs, the utility might overwhelm the visual repetition, though.

@epriestley, thanks for the examples. The second variant would offer the best ergonomics for copy / pasting, but of course it would also change the rendering of the heading.

This will link both:

Concretely, since this is presumably about the WMF install and you already maintain patches, this is the one-line edit required to make the change you're asking for:

Concretely, since this is presumably about the WMF install and you already maintain patches, this is the one-line edit required to make the change you're asking for:

@epriestley: Plain HTML copy / paste works with most WYSIWYG editors, both online and offline. It is also a lot more discoverable, as people are used to it just working.

One vague idea is that it may be possible to use a Google Docs plugin. The "Google Apps Script" development environment was a bit of a test in patience the last time I used it, but basically you can write "Add-Ons" and publish them to the "Google Apps Store", and then users can install them. This is sort of the starting point:

Or if it's helpful, I could link something else like the header/title.

It's not a big deal for me since I use Chrome to re-link the crumb. It's two clicks in the URL bar, or two clicks in the crumbs. But I think Safari it's 3 clicks...

I frequently link to phabricator tasks on wiki pages or in google docs. The current workflow to get a linked task number or title is rather cumbersome:

After D17103, at HEAD of master: