In HEAD of master, keys now have a detail screen which shows a transaction record. Clicking the key name will take you there:

Same here. I've created customfield "Requirement" to identify external Requirement ID. Searching using Contains Words is inadequate cause it search all fields containing similar string.

Can you list out a complete set of reproducible steps to follow? Is this a Dashboard you're building and installing on other people homepages, for example?

That is actually a great idea and way more elegant. Keep up the great work and thanks for your effort!

Source code isn't (AFAIK) stored in Phabricator's databases; it only lives at /var/repo/ and whatever other URIs you're mirroring/observing in Diffusion. But again, if you're just looking for commit-level metadata, using Conduit will probably be easier.

The use case is take all of that info as ETL input, but I what to be sure that I am not retrieveing source code from the tables as a matter of performance in addition to I am not interested in it.
What do you think is the best way to do that?

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.

Agreed with the systemd part, that would have been just for convenience of new users.

In T10460#162318, @teror4uks wrote:

I am solving this problem. Reason was in empty Callsign in setting repository. After I added callsing, revisions became openable for audits.

P.S. Sorry for my english.

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.

In T10989#176079, @Danny_B wrote:

It's logical - you can not build reasonably working application on wrong dataset. One would assume, that maybe in future, Phabricator (either directly or via an extension) will have support for such stats too (as it currently already has some stats such as burnout charts or so...)

In T10989#176072, @epriestley wrote:

These are third-party extensions, not other upstream applications, right?

Yes.

Why do you consider this to be a bug in Phabricator rather than in those extensions? Does the documentation say "this field is updated only when a 'meaningful' update is made to an object, and you can and should rely on it to have this behavior when extracting data from Phabricator" somewhere?

It's logical - you can not build reasonably working application on wrong dataset. One would assume, that maybe in future, Phabricator (either directly or via an extension) will have support for such stats too (as it currently already has some stats such as burnout charts or so...)
Inability to do such stats due to unreasonable dataset below makes Phabricator (otherwise good application) useless for teams which are trying to improve (read: shorten in this particular case) the task life-cycle - and that's pretty much every team since noone wants to have long time untouched tasks without any action taken... ;-)

In T10939#176076, @eadler wrote:

I'm referring to the home page dashboard.

By this I mean: as installed on the FreeBSD install.

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.

I'm referring to the home page dashboard. I just made some config changes (particularly, changing the limit of the number of revisions to show) and it seems to have 'fixed it' so the problem above would be PEBKAC :/

Selecting Exact Projects: Searching for a superproject currently searches for objects tagged with that project or any subproject. We may introduce a function like exact(#superproject) in the future to search only for a superproject, exactly. However, it's not clear if this is really necessary or has any use cases.

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

But moving on the workboard is no update at all... It is null action.

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.

In T7090#93682, @rag3rac3r wrote:

SELinux is currently disabled (until everything else works, then it's that project).

The Permission Denied is the result from when the SSHd tries to execute the 'phabricator-ssh-hook.sh'.

The log output is the following:

Jan 29 00:16:44 sshd[19506]: error: AuthorizedKeysCommand /path/to/phabricator-ssh-hook.sh returned status 126
Jan 29 00:16:44 sshd[19506]: error: AuthorizedKeysCommand /path/to/phabricator-ssh-hook.sh returned status 126
Jan 29 00:16:44 sshd[19506]: error: AuthorizedKeysCommand /path/to/phabricator-ssh-hook.sh returned status 126
Jan 29 00:16:44 sshd[19506]: error: AuthorizedKeysCommand /path/to/phabricator-ssh-hook.sh returned status 126
Jan 29 00:16:44 sshd[19506]: error: AuthorizedKeysCommand /path/to/phabricator-ssh-hook.sh returned status 126
Jan 29 00:21:36 sshd[20143]: Disconnecting: Too many authentication failures for vcs-user [preauth]

Some trial and error showed that it occurred when the script attempted to run ./bin/ssh-auth

[[ URL | name ]]F1648524

D14566 might fix this? See also T9640.

PHP7 is currently unsupported, I would start there and move to 5.6 or whatever you prefer.

Yes, I tried it on my work computer (same versions and configuration), and then on my home computer.

Can you reproduce this on another machine?

Inlined patches are now highlighted more nicely in HTML mail.

If you really want to muck around in Phabricator's databases, you could probably get at the information you mentioned with something similar to

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):

#twitter hat off. FreeBSD hat on.

I have been unable to repro on a clean install. Its probably appropriate to close the bug. I apologize for being unclear.

Or maybe a better way to think about this, we'd prefer looking at absolute, programmatic solutions, not solutions that rely on users discovering and consistently applying them (they won't).

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 think it's better to understand the deficiency of Phabricator's notification system than to build out something like this. It's not something I recall anyone previously needing or asking for, and seems completely undiscoverable.

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:

Thanks!

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).

I think the "Details" links would add too much clutter in plain text email

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:

or that

Better to do the header tags in the body text thing?

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

Yes. I think this has two general components:

Is this task open to be Prioritized? Wikimedia is discussing the possibility to fund it at https://phabricator.wikimedia.org/T135327

Is this task open to be Prioritized? Wikimedia is discussing the possibility to fund it at https://phabricator.wikimedia.org/T135327

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.

Ok. I assume you know about such issue so you prefer not to report it in future?

Thanks for the quick fix.
I realise now I was always trying to change the access policies....

The reason why I want that data is not relevant. The question in brief is the following the source code versioned by the repositories hosted in Phabricator are held in the data base?