Thanks @epriestley . It seems my search skills failed me this time... :)

In T9905#150315, @nicolast wrote:

I lost the preview (after a code update) while creating a new task on Maniphest. I it possible to restore it?

Please excuse me if this is not the place to ask for this:

I've updated the description, but I currently expect to promote these changes next week.

In T9905#148799, @avivey wrote:

Editing tasks via the editor now also subscribes me to them (eg https://secure.phabricator.com/T3277#148797); I don't think that's intended?

@ox: stable is very close to the edge. I think if you want production use, you should just use stable

Is there an expected date when this change will be safe for production use? That red warning bar at the top of the summary is very intimidating, though I want to keep our instance responsibly close to the edge (should I just use stable?).

I'm going to assume we're in the clear on this.

Editing tasks via the editor now also subscribes me to them (eg https://secure.phabricator.com/T3277#148797); I don't think that's intended?

This has been live for about a month without any major issues cropping up.

Excited about this too!

True... but I could not find a specified favicon.ico location when I did a CTRL+F for this in the HTML source code of this installation and our installation and assumed that there was some fancy JS code going on or whatsoever which

I don't think any of those actually specify the favicon... what does this return (with the right domain)?

Just to be clear, after this week - sites that upgrade but are tracking the stable branch will be affected by these changes?

These new features are exciting!

The basics of the ApplicationEditor stuff are now live on this install, and T9908 has some discussion of the direction I think we can pursue for the "Security" use case.

I landed what I've got so far, pushed it here, configured it a bit, and described what I've done in T9908, for the curious.

(consistent edit endpoints in Conduit and custom task forms are what I'm most looking forward to)

Actually, you probably also don't really care about removing the comment event anyway, since it can't change policies and you can't comment on objects when creating them, and I think your listener doesn't actually end up doing anything special for the actions that are available? So this might be mostly moot anyway, but in an ideal world I'll get through the main "edit" event shortly too.

Quick update here: ApplicationEditor/EditEngine have caught up with this, so the current plan is to indirectly remove this event in at least some cases (currently: changes made from the "Comments" area) after the stable cut on Saturday. You can upgrade to this week's stable safely but we should make sure things are in a good place before you move beyond that.

That's sensible to me. Was just an unexpected side effect of improving the arc land workflow for git and thought I'd mention it.

This was an intentional change in response to requests by other users in T4333 and elsewhere.

On this issue, it would be great to tune the behavior regarding "Author date" vs "Commit date" for git. With our current CI tool, current build and previous build are determined in "Commit date" order not "Author Date', which can result in confusing links.

@epriestley: FWIW I don't mind doing the work, and I would love to throw away all the hacky stuff we have right now.

I'm not 100% sure it actually works, but you'd just do this:

In T9860#146391, @epriestley wrote:

I believe if you include a transaction which sets the CCs to the current CCs, it is guaranteed to run after any personal rules and will entirely undo the effects of any sneaky rules anyone might write.

The problem is, we add a rule that includes "subscribers can view" to the policy - so even if it prevents mail from being sent, by the end of the herald processing, the user has gained 'can view' on the private task (by way of being CC'd) even though they should have never been able to CC themself in the first place.

I believe if you include a transaction which sets the CCs to the current CCs, it is guaranteed to run after any personal rules and will entirely undo the effects of any sneaky rules anyone might write.

In T9860#146319, @epriestley wrote:

What are you doing which can't be covered by Herald?

Broadly, we're in no rush to get rid of these events -- definitely no need to panic. I just wanted to push things in the right direction after T9851 was filed, which originally asked for the scope of these events to be substantially expanded.

My recollection, at least, is that Herald wasn't originally suitable because of T6367. Prior to that task, an "attacker" could write a rule like this:

/me patiently awaits @20after4's response, after being directed to this ticket from Wikimedia's Phabricator instance

What are you doing which can't be covered by Herald?

→ →

Excellent, thanks for following up! I am glad it wasn't just some strange issue for just us.

@mbishopim3, yeah, looks like you're lucky winner #2 on this. Your workaround (creating the database) was correct.

Yep, that was the issue. I needed to pull down some changes so I actually ran:

If you do this:

Also, there is nothing in my .gitconfig about [remote].

Woops. I just assumed that since git remote show origin listed the branch as tracked under remote branches, that it was tracked.

Can you show me this?

I successfully was able to land onto a remotely tracked branch other than master but hit this:

I'd like to see more users encounter difficulty here before pursuing any of this.

APC and APCu are different. Basically:

OK - so I tried to install apcu into php farm with:
pecl -C ./pear.conf install channel://pecl.php.net/apcu-4.0.2

But you say the message was preferable to the consequences of the possible fix without APC?

yes, message has gone. But you say the message was preferable to the
consequences of the possible fix without APC? I'd be interested in knowing
how terrible the consequences are!

When APC/APCu are not available, we fall back to a disk-based cache with worse performance characteristics and much worse cache semantics than APC/APCu provide.

Apache 2.2.22(Ubuntu)

This has been in stable for more than a month without any followup issues cropping up.

I don't think that use case is strong enough to justify making this mechanism more complex. Some ideas: