I'll tweak the logic, I agree that, e.g., "index.js" should be displayed in your first screenshot (and probably whatever's above it if you scrolled up just a little bit more).

• persistent header element is a great idea
• scrollbar annotations are very helpful

Evan, rP52c4715bbcfb solvedthe issue. Losing low-resolution profile images is no problem.
Thanks for the quick solution!

This is a bug in the upstream. D17770 (or some similar patch) should be available later today.

We may eventually build this for T7413 but I don't think it's a good use of our time without a strong, narrow motivating use case like that.

T7413 is security/usage data.

That's a good point about also accumulating any security notes

(There's no need for a token to get the changlog via conduit)

Asking someone who is say, 16 months behind to read 80 changelogs seems detrimental to having people keep up to date.

This is partly why I would like this -- the Upgrade / Compatibility section of changelogs is probably the only near-mandatory sections to review before upgrading (things might behave differently until you do databasey things, the way a configuration behaves has changed, etc.). My process for upgrading right now begins with reviewing the changelogs to make sure I don't miss any pre/post-intall steps, and I'd like to automate part of that if possible. For a site that's upgrading weekly this isn't a challenge, but sites that are unable to upgrade as frequently would (should?) be sifting through this stuff anyways. I think this would be part of community resources and not officially part of Phabricator.

I am however, all for making Phriction better and supportive at the CMS level for navigating / categorizing content.

I don't think there is a lot of benefit here, and worry it might actually detract someone from upgrading. We already post a changelog here, via email, and on social media. Asking someone who is say, 16 months behind to read 80 changelogs seems detrimental to having people keep up to date.

Did I really have an extra space in the title

I think that's right, yes.

The table in the description references a getConduitFieldKey method – which I can't find reference to ever existing in the source. Was that supposed to be getFieldKeyForConduit?

I'm probably going to add a note to the dashboard dialog explaining home special casing better

This has been live for a while now.

This has seemed stable for a while. We've fixed a few stemming issues and have T12137 and some other followups outstanding, but these generally are not issues that are fundamental to InnoDB Fulltext.

I think we mostly managed to get installs through this.

This has now been live for a while without anyone hitting real issues other than the minor hiccup in T12090. T8475 is an eventual followup.

This has been live for a couple of weeks and I don't think we've seen too much confusion from users.

Presuming this is resolved since it's extremely boring and I ran it here and on every instance in the production cluster last week without any issues, but yell if you run into problems.

If they need to bridge the difference as some fields are migrated and some aren't consider something like

For the record, D17207 is needed for any custom field implemented in accordance to this ticket (without shouldAppearInCommitMessage) not just ones in the not-editable special case.

Sweet.

Awesome. Things appear to be working now. I suppose I can strip out all the overrides that the most recent commit stripped out. Sweetness.

Yes, if you aren't in edit mode. Here's normal mode (includes field):

so if isFieldEditable and isTemplateField are both false, will the field still show up in getcommitmessage?

In particular, your code may just work as-is after updating. If not, compare them with those "MagicFlag" fields and/or let me know what you're still seeing?

Alright, after D17207 I think these are analogous to what you're doing?

ok, probably tomorrow

uhoh

I plan to land several fires

Solid.

Hour or two if nothing's on fire -- probably today, just later this evening.

Awesome. What do you think the time delta will be between release promotion and the fix you have being merged to master?

@jmeador, I think I have a fix for your use case but it touches enough stuff that I'm going to hold it until after release promotion. Your use case is a bit unusual but should be possible to support.

shouldAppearInCommitMessage() is marked as obsolete, but still seems necessary for me to implement a CustomField that behaves as follows:

(2) and (3) are correct.

Thanks!

Applied D17001 and confirmed fix. Thank you.

> select @@innodb_ft_max_token_size;
ERROR 1193 (HY000): Unknown system variable 'innodb_ft_max_token_size'

What you describe sounds familiar. I can find NTP and EoL. I can find NIS* but not NIS, DNS* but not DNS.

That's expected if innodb_ft_max_token_size is not defined; specifically if this returns an error:

FYI this is where things are at after storage upgrade on Week 49 stable using MariaDB 5.5. Is this what you would expect?

Note that full text indexing for InnoDB and hence innodb_ft_min_token_size were only introduced in MariaDB 10.0.5. RHEL/CentOS 7 ships with MariaDB 5.5 :( Ref: https://mariadb.com/kb/en/mariadb/fulltext-index-overview/

Found it and edited my comment, it was indeed innodb_ft_min_token_size at fault.

What is innodb_ft_min_token_size set to? The default is 3.

After this update I couldn't find three letter words any more. I needed to add this change to the MySQL config:

@csilvers, not sure if you got directed here from IRC. See also T11932. At HEAD, we'll now issue more explicit guidance about the required index rebuild.

This has been live for about two months without any substantive issues arising.

@vanmeeuwen couldn't you use custom forms to lock/hide the policy controls on the maniphest task submission / edit forms? That's how we handled it at Wikimedia's Phabricator. As mentioned above, Custom Forms is the general way forward for controlling default task policies.

Ut seems to be T10145

Or if it isn't, please file a bug report.

This change didn't touch Dashboards. I think you want T10612 or maybe T10145?

I think this change broke dashboard editing slightly. Now when adding a panel to a dashboard column, the same panel gets added twice, once for each column. Removing either of the dupes removes both.