See some discussion of SELinux in T4947. We'd prefer to find a way to detect that SELinux or AppArmor are running, and warn the user only if they are affected. We've generally had much greater success with raising specific setup warnings during setup than with putting notes in documentation (which users often do not read). We do not currently have a test for SELinux / AppArmor, although it is possible that these tests are straightforward.

Third-party applications which assume dateModified means "last 'meaningful' update" are written incorrectly. It does not mean that, it is not documented to mean that anywhere, and it is clear from the code that it doesn't have this behavior. It is unreasonable to assume that the only possible purpose of this field is metric extraction. This field is a low-level field which serves a different set of goals. It explicitly does not serve metric extraction goals.

Ah! Okay, cool. Not really PEBCAK, I need to fix that dashboard too and it's super confusing that it does something weird/different with no clues about it. I just wanted to see if anyone caught major issues with the new one before swapping it.

In fact it breaks various monitoring/statistics depending on last update

System-specific configuration like SELinux and systemd is outside the scope of Phabricator. See T4200 for discussion.

https://secure.phabricator.com/book/phabricator/article/diffusion_uris/#observe-a-repository

"Last Update" is low level, and includes some actions which do not appear in the task history. This is expected.

Inlined patches are now highlighted more nicely in HTML mail.

The default is still

That's not expected, but I can't immediately reproduce it. Here's my local install, note that D4 appears in "Ready to Review" even though I (admin) am only a reviewer via project membership in Stonework (a project):

I also agree with @chad in the general sense -- this use case seems pretty weird to me and is entirely unlike anything we're aware of in other installs. If email notifications are deficient in some way, we'd prefer to address that.

I suppose you can arc set-config browser <something>, where <something> is a script which copies argv[1] to the clipboard and then exits, then run arc diff --browse.

Roughly, you should be able to:

You can subclass MetaMTAEmailTransactionCommand, following DifferentialActionEmailCommand (which does Differential stuff) and ManiphestPriorityEmailCommand (which is a better example of implementing an individual command), to implement !hahaha-yes-i-definitely-reviewed-this-hahaha which applies !accept only for small diffs.

Here's my technical plan on this:

We can't easily link to an #anchor from email because the transactions that render in email are different from the transactions that render on the web. For example, T10493 is a case that specifically shows a transaction in email but not on the web. Since it doesn't exist on the web, we can't easily generate an anchor to the corresponding transaction because no web version of that transaction exists. This behavior is not unique to that transaction type. Anchor generation is also more complex than this for other reasons (for example, transaction are grouped, aggregated and reordered at display time, and these changes affect which anchors are available).

D15942 restores the project tag transaction to the first mail about an object:

I guess this originally had several different parts. My thinking on the parts are:

I think we're mostly unsure what we want to do here.

Yes. I think this has two general components:

These tattered edges are an expected consquence of destroying objects, and the Phabricator upstream will not help you fix them. We strongly recomend disabling or archiving objects instead.

Yep, works now. Thanks

Thanks, try HEAD?

I'm not sure if this change is correct, but it seems to fix the issue for me: https://secure.phabricator.com/differential/diff/38381/

arc diff is not expected to upload coverage information without additional configuration.

I think the output format from differential.parsecommitmessage has changed:

Oh, this is probably the correct error log:

Server-side, I have the following commits deployed:

You're also two months out of date, see Contributing Bug Reports.

Please include reproduction steps when filing a bug report. See Providing Reproduction Steps for help.

Blocking reviewers can now be added, edited and removed via the web UI with the blocking(...) function. For example, entering blocking(epriestley) into the "Reviewers" typeahead will add epriestley as a blocking reviewer. You can use this to upgrade reviewers to blocking or downgrade blocking reviewers to non-blocking.

I've consolidated the general state of the world in Audit in T10978. I think we'll run into some of that eventually but I'm not sure how much is important vs nice-to-have, so my general plan here is to just scratch the surface for now:

See T3498.

When we can identify the author, I'm just going to make auditing stop trigger audits by any packages they own, even if there was no review.

Presuming this was fixed some time in the last four years, barring any new reports. The code has code to do this, at a minimum.

I think this was effectively resolved by T8004 / D13923.

At HEAD (after D15929), bucketing is now more considerate of individual reviewer status and cases in T5217 should be handled in line with user expectation.

I'm going to merge this into T10967. Although it would be possible to fix in advance of that, I think it is unlikely that we'll pursue the changes outside of the larger infrastructure changes discussed there.

When you deleted the user, did you see this prompt?

At HEAD, I can't reproduce this:

I think this is covered by T8612, unless you can produce a small change which requires a disproportionately large amount of time to render. It is expected that large changes will take a proportionately large amount of time to render.

No clue how to reproduce this and haven't seen anything similar in the ~year since. File a new one if you have some idea how to repro it.

But a root owner's accept will still count for the sub-package, provided dominion is weak?

The driving use case for this fell through, and I no longer plan to pursue it.

Ah, thanks for following up. That's interesting and a little perplexing, although just fixing this stuff via T10967 is probably still the best way forward. I'll keep an eye out for similar reports, though. That does tend to make me think it might be a real race.

I'm going to merge this into T10967, since after digging around in the code a bit recently it seems unlikely that we'll pursue the infrastructure changes required to fix this outside of the context of that larger infrastructure change.

I expect that when a package is defined with Auditable enabled, each commit that affect the package will trigger an Audit rule.

(I'll restore viewer(), it's just not a one line change.)

In T10939#175557, @epriestley wrote:

Yes, since it would really mean exact(current-viewer) without additional work. Are you using it for something (dashboards?)

Just to make sure I'm understanding correctly:

I can only reproduce this if (3) is changing "Visible To", exactly: i.e., same file policy scrambling issue as T10778. Should have the same fix.