It's on Phacility.

It looks fixed, thanks.

Having the ability to mark certain fields as required would certainly address the root issue but looks like it might be a long time before this is addressed no? This task is close to a year old.

This problem is happening for both the notification popup as well as the dedicated notification page.

Let me try to rephrase: "I would argue that showing entire app components to users that cannot be used is a UX bug".

I always use this menu to access the special items as I have no idea what to type to auto-complete them e.g. "not in any project".

Case in point: as a non-admin, clicking on "Config" here:

I can only agree with your position WRT hypothetical requests, but this task is a UI bug in my mind, not a hypothetical request. There's no reason for a non-admin user to see admin apps at all, which they cannot do anything with anyway: it's just setting the user up for failure.

Unfortunately we are on Phacility so that would not be an option.

I wasn't trying to revert, I was just trying to copy-paste some of the markup of an old version of a wiki doc. Since I was copying from a previously deleted section, I understand why the result was empty: it was copying from the right side of the diff which was empty. That said, that was very non-intuitive.

Actually the same problem if you are looking at the result of a query in Maniphest, so it's a generic problem.

In unified diff, it works better but still not correctly:

So is the idea that "safe mode" is going to be enabled for all accounts on Phacility?

From your point of view as an instance administrator, do you think this is valuable enough to spend 2-3 days building instead of other features?

To add more context for when I say I didn't do by accident, it's because I didn't read the fine print, so ultimately it is my fault. BUT I didn't read it because I would expect only 1 important thing in there: the name of the instance to suspend. And since I had only 1 instance, it was pointless to read. It turns out there are 2 critical pieces of information in this dialog: the target instance AND the fact you cannot re-enable it on your own even though the UI hints otherwise.

The other problem with the current dialog is that the default action is the destructive one, so just pressing Return will accept the dialog, which you can easily do by mistake. Forcing the user to enter the instance would also address this problem.

I wouldn't say trouble, in the sense that I knew it was the confirmation dialog and I clearly understood how to use it 😉

I didn't confirm by "accident". What I did by accident was disabling the wrong instance which would be solved by T8879.

Got it, thanks!

The "Pusher's projects" rule could be some other qualifier (e.g., only administrators, etc).

In T7005#125352, @epriestley wrote:

You can add such a field yourself:

https://secure.phabricator.com/book/phabricator/article/custom_fields/

It would be ideal to have a direct wiki link in this nav bar when looking at a project:

Since projects can have custom fields, how about a field that's for a link to a wiki page?

From T8779

+1 to get this to happen. Easily and "officially" connect a Phab project and a wiki page is very useful, especially for new users when needing to navigate around. You can certainly make a convention but then it needs to be enforced and this never works 100%.

Got it, thanks for the feedback!

OK maybe not 2 seconds, but watch this movie (I show the UI problem of dragging not working at the very end):

• I don't see how this is inconsistent with existing actions: the menu does not contain only "Add" actions today: Change Status, Change Priority... so you can have "Change Projects"
• How is this different from race conditions if 2 people edit the task at the same time (using the main form)?
• A comment field to Edit Task might be a good thing in itself, but that's separate from this issue which is to make a common UI action (removing / replacing project) as efficient as adding projects

This is surprising to me, since Facebook had people whose responsibility this was (from pretty early on, I think). I do most of it in this project. We don't have a huge volume of tasks (about a dozen a day) but triage takes very little of my time.

I'm fine with having support for this in Herald vs truly built-in. What matters to me is having the automated ability to ensure every task is going to be looked at by someone. There's never going to be a 100% full-proof solution, but requiring neither project or assignee increases the probability of lost tasks which I have seen in practice. Having a designated task janitor to regularly look for tasks without projects and redirect them is not practical nor reliable IMO.

I agree that putting a bunch of text that needs to be deleted each time is not the right approach. Maybe as part of the arcanist flow, after saving the diff but before sending it to Phabricator it could prompt (assuming test plans are required in the config):

Did you write a proper test plan?
(one or two sentences go here)
For more information, visit ...
[y/N]

Ah that explains why we saw some files failing to upload both under command line and drag & drop in Phriction / Maniphest but working fine from the /file app.

Projects in Phabricator have associated workboards where you can visually organize their tasks, see https://secure.phabricator.com/project/board/519/ for an example.

You need to use the Edit action in the column menu.

So one thing you could do is display a hint at the bottom of the completion menu like "Archived projects only appear if typing their entire name" (even if not technically correct since you need to type enough letter, it's easier to explain and understand).

Ah you're right, I just need to type enough letters to work around the ambiguity and it works.

$ search index --type PROJ --all
Run this workflow with "--background" to queue tasks for the daemon workers.
Indexing 137 object of type PROJ.
Done.                                                                         

Didn't help.

No it really doesn't work as of right now:

I've heard a few requests at our company in the recent days now that we do more "serious" project management, to have cards in workboards display the secondary projects. Any chance to get this rather soon? It's already behaving like this in Maniphest. People love workboards otherwise!

Yes.

I realize I'm still missing a piece: I thought you could do that in Herald but apparently not: adding a comment to a task when a rule matches. This would be needed to not just blindly re-assign the task to the author but also add some context.

Very interesting, thanks much @epriestley.

Maybe only git and svn should be supported then?

@epriestley the patch you provided appears to work after a few days of testing, thanks.

Do you think I can build a tentative document include solution through a remarkup extension?