@epriestley, see inline.

This allowed investigation of a problem that doesn't seem to exist any more, so isn't necessary.

Agreed. I haven't experienced the problem since I upgraded, so I think it was related to an earlier fix, even if it wasn't the identified fix (which should have already been in my install when I did have the problems). There's nothing that needs to be addressed here.

+1 for not adding undo behaviour. I too avoid yellow undo bars by saving empty comments. Alternatively, I guess, you could put a "Permanently delete" link in the undo bar so with one extra click you could whisk it away (which actually would be easier than going through the edit, empty, save dance).

We could change the behavior to "tap and hold to begin a range + drag".

I do think "Quote" needs to be somewhere (it wasn't listed at all in T11401#224171, though you mentioned it). Shift-click on reply could also be supported, but such a power user feature is far less important than an easily discoverable function. I believe that I personally would use "Quote" more often than "Edit", but honestly would be happy wherever this were put. I'll probably upgrade my Phab instance and start using the "R" shortcut next week either way.

One thing I noticed. All three daemons (Taskmaster, Trigger, PullLocal) are listed as "Waiting" on my install currently, and also show up in the output of phd status. When this problem occurred, I didn't look at the Daemons app in the web UI, but I did notice that Taskmaster was not listed in the phd status output. I'm guessing that behaviour is not normal and perhaps provides a little insight into what's going on here.

I've adjusted my monitoring to just alert me instead of restart the daemons when there's an issue so if/when this happens again I can investigate more fully/provide more information. The code from D17397 had definitely landed when I experienced this, as I saw it in the source code when I investigated. I've upgraded to current stable now.

I made a diff (D17780) that adds bin/phd check which runs the setup check that the web UI runs, writing the result to the console, and exiting with an indicative status. This at least allows the circumstance to be detected and I can fix up the problem with bin/phd restart. This might be good enough. Even though using bin/phd start or having Phabricator self-repair through the Overseer would be better, it's likely too rare to warrant work on more complex options.

IMHO, that's more likely what you want in most use cases anyway. I can imagine
quite a bit of confusion arising if you modify a query for a dashboard and it
unexpectedly modifies what shows up elsewhere.

See T10038: Plan the mid-term pathway for unit-test/linter bindings and Community Resources.

Something that would be useful to us would be the ability to create, or probably better, assign a task, as it nears a due date. E.g. we may set up a task due in a year's time, and anticipate working on it two months before it is due. It would be great to be able to schedule the task to be assigned on a particular date, and perhaps moved on a workboard. I don't think this would need to be any more complicated than a Herald action that runs at a particular date/time rather than in response to some other action. I'm not familiar with what Calendar can already do, as we don't have prototype applications turned on for our install, so apologies if this is already possible. I just thought I would mention this use case here for future reference.

Thanks for the pointer. I wondered if there was something like that I could hook into.

I don't have a problem grouping the use cases together, and it makes a lot of sense to solve as many use cases as possible per feature. I just wanted to point out the differences so that when this task progresses, it can progress with the different use cases in mind. At a first glance, I didn't think the use cases were very similar at all, as this is a lot about creating a bunch of tasks by template (or from a template project), which is a bulk action, really, whereas really our use case is about task micromanagement. However, on further consideration, there is significant overlap, especially from what T3320 brings to the table.

I see there is some similarity, but some important differences in the use cases:

• We are interested in splitting a specific task, crafting the title and description in particular, manually (in fact, with quite a lot of care), whereas here the focus is on creating generic tasks, or templated tasks
• We would not want subtasks to be copied, I don't think
• We need to be able to edit the original task at the same time as creating the new ones, whereas there is no aspect of that in this use case

Another possibility for assigning to members not already on the board would be to add an "Another User…" category, perhaps only once you start dragging, and if you drop on it, you have to select/type a user in a modal dialog to complete the 'drop' operation (or cancel it). This might work better than guessing; every column would have "Unassigned", headings for users with tasks actualy in that column, and "Another User…". On the other hand, for us, guessing is likely to result in a lot of wasted space, because the users we assign to in different columns are very different. The feature would quite probably be useful to us, though, as moving columns concurrently with reassignment is an extremely common task for us.

Thanks for that confirmation. I like the look of your code comment: "Possibly we should white-list this kind of mail and deny all other types of mail." I'll create an enhancement request task related to that.

Re scenario 1, I found another way to investigate it rather than digging up old logs. Question, though: is Phab supposed to send email to users who are unverified? Looking at mail logs, it seems one of our most recently added users was sent quite a lot of mail, perhaps all mail they would ordinarily get, prior to verification. If Phab is supposed to send mail to unverified users, then this would be an enhancement request which I could submit with a proper description of the use case. If not, I can investigate how to reproduce the behaviour.

Related thought: I wonder how the sticky task order fares when a task is on multiple workboards; since the subpriority seems to be a task parameter, not a workboard card parameter, I guess moving it on one workboard may clobber its position on another; quite possibly not a problem in practice.

OK. The type of the other transaction is subpriority. From the database:

Initialisation doesn't seem to fit the pattern, as I would have expected an earlier column change to trigger it if that would. There are also over a dozen transactions on the timeline of this task before the section I pasted here, including comments (one deleted; I wonder if that's relevant), column changes, reassignments, and status changes.

Yes, both. I don't see how either of those could be involved with a column change, though, could it? Changes to our custom field do show on the timeline, too, but nothing is showing here.

I wouldn't call this resolved. Invalid may be most relevant, as with no STR, we can't confirm or action this.

Thanks, Chad. I've just used the Administrators group and adjusted the EditEngine permissions, which is sufficient for us; anyone authoritative enough to create blogs is authoritative and technically proficient enough to have admin privs, too.

My concern here is the specific request only solves a side-effect of the root problem, and not the root problem itself.

Aside from that, I don't think it's too much of a stretch to say that as a general principle, permanent/irrevocable subscription to an object is tantamount to spam.

In T11687#195734, @chad wrote:

In my administrator/management role, I create a blog for someone else to write posts for

Why?

Sorry. I thought the root problem was obvious. I guess not.

Cool. Well that clears up one concern right away. :-D

This it exciting, @chad and mostly I like the look of it.

I was experiencing this problem too and it works in current stable for me now.

No! I hadn't noticed it, sorry. I've had a look now and will endeavour to give some specific comments over there later. I don't think the 'addressing comments in multiple updates' will be a problem, though.

It's vaguely possible we could use a bunch of Javascript to try to capture the path that an edit takes and then submit it alongside the new text to track inlines, like Docs/Word do, but without implementing WYSIWYG. I suspect this would still be very complicated.

I think it's right to leave the options there, too. Sure, it's two controls, and they don't make much sense to use in certain combinations, but it's totally intuitive (as is the parent/subtask terminology, as opposed to the blocking/blocked terminology).

Yeah, D16340 looks good to me and should perform similarly. I'll raise any issues when I upgrade, but I don't anticipate any problems. Thanks for sorting this out!

• fix the variable typo;

There were a few intervening commits, which surely would be normal following a review process (?), but I note that arc land has merged my change into current master rather than rebasing it onto current master. As there don't appear to be merge changesets everywhere in the repository, this doesn't seem to be the norm. Did I do something wrong? I just ran arc land hidden-anchor-fix as instructed by 'Next Step' in the web UI. Should I have instead pushed the 'Land Revision' link in the UI, or rebased manually immediately prior to landing, or something else? Would be handy to know in case some of my other work gets accepted. :-)

Rebased to master and updated resources/celerity/map.php

Thanks, @epriestley. Just one question: I note that resources/celerity/map.php is in the repository, though it is auto-generated, and that changes to it seem to be incorporated with other changes (i.e. not separate commits from CI). Therefore, should I rebase this onto current master and run bin/celerity map before landing, or something like that?

As was mentioned, there was code already for detecting a hidden hash/anchor and loading older transactions/comments to allow it to be reached. Turned out it was a cinch to hook it up, which I've done in D16256.

• Choose the default colour+icon picture for the project
• In the project history, click the link to the file that has been assigned as the picture
• Note that the file is temporary, so will be cleaned up by the garbage collector

Thanks for the feedback. I'll sit tight. You know how to reach me if there are any problems or requests related to this. :-)

@chad indicated that @epriestley reviews code from contributors, so adding him as a reviewer.

Not wanting to nag, but it's been a couple of months since I submitted a diff that fixes this. Would it be possible to include it? Have I done something wrong? Perhaps @chad would know?

I've upgraded our instance now this has hit stable, and our team is thrilled. The interface may not be perfect, but it satisfies the vast, vast majority of our use cases. Thank you!

@epriestley, have I done the right thing submitting a review here for this? Could you spare a few minutes to accept/land it, or throw it back to me for further work? If I should be following a different procedure, please let me know. No pressure; just a gentle nudge and plea for guidance. Really appreciate all your work and respect your right to set your own priorities.

Does this being added to 'Prioritized' mean Phacility are working on it, so
there's really no point in me plodding along trying to do it? :-)

P.S. It's not an April Fool's joke....

I guess you can tell from the history that I put together a patch to fix this and submitted it as a differential revision. I hope it may be considered appropriate for inclusion (and am wiling to do further work on it to bring it up to standard if necessary). Thanks for a great product!

Evan basically answered my question in T5214. There are good reasons not to expose an API at this point, as due to possible future changes, it might be unstable. I'll try to figure out how to do these things within Phab only, perhaps by creating myself a temporary outdated-style API. Then I'll to understand the second bullet point above more fully. I'm pretty comfortable I understand the point made about EditEngine.

Thanks for the guidance. The exact UI is a minor detail. I'm pretty happy to contribute towards either of your leading contenders (and don't like either of the possible contenders much). But as you say, that's not going to become an issue until a little while down the track.

Thanks a lot for putting your time into replying to my comments. I am thinking squarely in the context of T6027, and was looking primarily at the bullet points here as a stepping stone towards that. i.e.

Are workboards 'un-beta' now, and stable enough for it to be worth putting some work into this? I can't promise to have time, but I'm certainly interested in having a look at this.

@epriestley, I'm not sure if/when I'll have time, but would a patch for this along the lines of my previous comment be considered? I'm conscious it must be forward-looking to T5474, and might take a few attempts for me to get up to standard. If the core team can review/guide me, I'm certainly willing to give it a go as time permits.

Touché!

Ah. Looks like I just needed to upgrade as this change was made in the last month or so (I last upgraded late Feb). Didn't see this change mentioned in the changelog, or a task for it, so assumed it still wasn't possible. What you have implemented is perfect for us. Sorry for the noise.

In T1130#118470, @epriestley wrote:

They're a function of an individual commit instead of being a function of the repository as a whole, so we'd have to do a lot more work to support them (it's not meaningful to, say, "list all tags in the repository", as it is with Git), ...