This is desirable, but complicated in the general case. T3875 (and T3875#182020 in particular) has some discussion of a similar identification problem at the other end of the workflow, in arc land.

Where did the phid get to the user anyway? If it's arc diff --update, it shouldn't try to parse the comment, and if it's arc diff --create, it shouldn't have any tags?

We can have this render "Tags: PHID-PROJ-abcdef" instead, which is an "improvement".

No this is just a general bug report since it's a fairly confusing error message for end users.

Are you looking for alternative ways to block commits, or is this a bug report about "arc diff fails when revision has secret project tags?"

Obviously I can implement this myself locally, but if it's a lousy idea for whatever reason, I'm hoping filing this request will cause someone to warn me off it.

T8200 describes a somewhat-similar issue.

Well, that sounds scary.

In general we want people to update if possible before filing a bug report. The reason is most real "bugs" are fixed usually same day reported. For example we had a recent "Repository is not attached" exception that was fixed same day, but we're still getting reports trickling in weeks later. Being on this week's stable is all we usually expect. HEAD of master is better, but not required.

I'm trying to figure out if I destroyed our files this weekend by migrating them or by using purge / compress.

Per above, I'd like to just fix issues here rather than add an automatic compaction process. I don't currently know how to generate un-compact files in modern code.

Actually....

Presuming this is fixed / irrelevant / not scary / resolved / something since I don't think this went anywhere elese, yell if not or I just forgot something (or we can follow up after T11044 if this is waiting on that),

First I apologise if I somehow came across with any hostility, that was certainly not my intent.

@ofbeaton How can we make the bug reporting guide more clear with respect that we don't take bug reports on older versions of Phabricator? Nor do we take feature requests or feedback as bug reports.

Thank you for the timely response. I'm glad to hear you're thinking about this. I still have many concerns about this that I hope you will consider.

This appears to be a problem unique to your environment, because we and many other users follow the upgrade steps routinely without encountering this or similar errors. In particular, I can't reproduce it given the information provided.

Not only that but the language has moved away from human-friendly terms like "hosted" vs "non-hosted" to "observe".

I want to also stress that the new interface does not communicate the different options available very well. The old wizard had radio buttons with things like "have phabricator host your repo" and "host your repo outside of phabricator".

çok güzel olmuş moruk ya halal olsun

In T11335#186091, @avivey wrote:

Can you configure gitblit not to expose these refs, ...

Thanks hach-que . I get remove php5.5 reinstall php5.6 and its running ok .

I use maniphest.query (which is marked stable).

They're available in the "points" field of maniphest.search.

maniphest.search method contains that under points:

Maybe I shouldn't debug things before coffee. getChanges is fine, the problem is something else; I think the recorded information might be wrong.

Not a rendering bug, it's a translation: https://secure.phabricator.com/diffusion/P/browse/master/src/infrastructure/internationalization/translation/PhabricatorUSEnglishTranslation.php$1571

Mostly, that's because getChanges in PhabricatorCalendarEventInviteTransaction is wrong - the phids in this transaction are in keys, not values.

I don't think we're really making any headway here. Here are some more actionable followups:

I don't want to continue expanding the existing "mail tags" system in Settings → Email Preferences. See some discussion in T11337.

No problem! We know this is pretty tricky to figure out right now, and plan to make it easier next time we do some work on dashboards.

I feel very stupid! Sorry for bothering you guys. A thank you very much for your incredible quick help! I think this should be closed...

In T11034#186209, @epriestley wrote:

The dialog can be resized by dragging the lower right corner.

Uh wow! Let me try this!

Sorry for the confusion. I know projects and tags are the same. But we have to kinds of tags/projects: Projects and tags. And we need on the dashboard a list which shows only projects.

If you can make the query you want in an application, you can use it in a Dashboard panel by following these steps:

Our problem is that the project panel shows both tags and projects

@epriestley No its about projects not tasks. I'll try to make the query you mentioned. Is there any possibility for custom query panels in the dashboard?

Oh, or I guess you're listing tasks? In that case, can you execute the query you want from Maniphest (at /maniphest/)?

Can you currently execute the query you want from the main query UI in the Projects application (at /project/)?

I know you guys don't like proposals for a solution so I put my two cents in a comment: The obvious approach for us would be a filter for the panel which supports custom fields. Or even better support custom fields in all query masks. Anyway thanks for this great product!

What about show only active projects in "Browse projects" window?

Hello! What about show only active projects in "Browse projects" window?

We've just been inching our way through this bit-by-bit to address specific use cases and improvements. That approach seems to be working pretty well and we have no plans to turn the whole mail into some fancy graphic thing, so I don't anticipate doing a specific whole-mail HTML redesign. We'll continue making improvements to specific sections.

We don't send from a static address, even in Phacility, since each install sends mail that originates from an install-specific address (@phabricator.mycompany.com or @instance.phacility.com). This is currently a hard requirement for these actions.

Per T7047#180833, no idea what the use case is for per-user/per-Herald/per-Mail.

This is a catch-all task that I don't anticipate us ever taking action on. Building some sort of templating system for mail would require a lot of resources, and using that templating system to accomplish some of the goals described in this task (like "always show associated projects") would not be significantly less complex than just forking.

We haven't seen other interest in this in about two years.

Presuming resolved by T11120 as we haven't seen further reports in more than two years.

I don't see anything we can do about Gmail's behavior here. Use a different client, or ask Google to improve Gmail's behavior.