It would be great if this were to integrate with the new feature that allows a limit on the number tasks per workboard column. This would allow you to easily assign a number of points to a sprint workboard without having to keep manual count.
Interestingly that option already says points limit but it does just increment by one per task added, rather than a cumulative count of points.

No worries, thanks for the link. I think I'll turn off auto-close entirely to avoid the issue until such time it does get resolved.

Do you know if this is likely to be fixed in coming releases? Any time I auto-close a review it gets multiple commits closing it which mess up the diffs. It's a bug I can teach users about and how to work around, but it is fairly obvious.

Thanks, I've resolved this and I do understand it's difficult with the docs.

Thanks for the clarification, looks that once that bug is fixed then the whole integrated with gitflow workflow will work.

When I set immutable to true and ran "arc diff" for the second time it won't update the review. However if I use "arc diff develop" it correctly updates, so that was the mistake I made when trying to update a review in immutable mode (the error was something like can't update a non-existent diff, I can't remember exactly). I just didn't get that you needed to use the same base point for the updating call.

I've nearly solved the problem during getting you those screenshots, teddy bear effect going for me there! Though it's not quite perfect it's nearer now.
I noticed that if you leave immutable off and do your updates via "arc diff develop --update D8" rather than "arc diff --update D8" it now correctly treats the commits additively in the diff view of the review. I assume that is because it creates a whole diff each time you do an update, so giving it the same starting point makes this work. If I'm guessing correctly then I wonder if develop changes between the original review and the update would this still break the diff view as the diffs would effectively have different baselines as develop code would be different in each case? If this is the case then even doing it this way will be a problem I think.

It wouldn't have to pretend it was squashed if differential understood that diffs could be additive instead of replacements of each other. If I could add another commit (or more than one) that differential knew was an update to a review, and thus the diff display in the review knew that the commit was additional changes. At the moment when you do this anyway (you have to have immutable turned off) it really messes up the diffs view. I wonder if I can create any screenshots of what it does at the moment to illustrate. I'll take a look.

If squashing is the only way to do this then I will still consider it, it's just that it's not always desirable to lose all commit history on a feature branch that has been going a little while and force pushing (which is the only way to update remote with the squashed commit) is something I'd prefer not to recommend doing as people who get into the habbit of it can mistakenly use it and can end up doing this (https://news.ycombinator.com/item?id=6713742)

That seems to have fixed the issue nicely. Thanks a lot :)

No worries, just glad you've been able to reproduce it and I wasn't going
mad!

This is not Ubuntu specific, I just tried this on Windows in Chrome and have the exact same issue.

Here is an mp4, and you'll see the difference compared to your video. I'm dragging up and down in a long list of a single column.

It's a windows video as that was the quickest way for me to record. It's
actually running in an Ubuntu VM however screen cap in VM seems to just
record a black screen. I'll try and find a working video capture app that
will record mp4 or something and re-upload.

I've reopened it as either there is something that I'm missing or this issue still exists. I'm happy to provide you any more information you need but for me this makes the workboards pretty unusable once they have a realistic amount of work in.

I have updated to the most recent code, checked I've got the changes by comparing to the diffs linked above, however I can still fully replicate this issue.
I've loaded the javascript for DraggableList.js in my browser and ensured it has the changes you've made (to ensure there is no hidden caching), turned off entirely any browser caching but I still have the issue.
I'm willing to believe I've done something wrong but I'm afraid I'm running out of things that it could be.

I'm going to do another installation from latest source, I suspect I must have made a mistake if you can't reproduce. I'll do it when I get into work tomorrow.

Alternatively is there a way to get the mutable version to work when commits aren't squashed and to treat commits as sequential? If you just do this anyway the diff displays go very wrong. I'm assuming that there isn't from what I've seen.

So the change to autoclose worked nicely, thanks. However I'd like to be able to use arc diff and arc diff --update, but that means I need to use mutable history it looks (otherwise it can't update the original diff, with an odd error message too, something like can't edit and emtpy diff rather than saying it's because immutable history is turned on). The problem with this is if I use mutable history it automatically assumes I am squashing the commits, and if I don't do that the diff displays are totally incorrectly and I don't want to enforce squashing of commits.

Thank you all for the very helpful comments, sounds like it'll help me do what I need.

Thanks, I'll take a look into doing those things too, especially the autoclose settings. Hopefully I'll be able to try it all out tomorrow morning.

I'll try it out and update here with results so if anyone else happens upon this then there is hopefully an answer.

And thanks for your help by the way, it is much appreciated and it sounds like there is a way to do what I want, I just misunderstood the process and differential a little.

When you say "before the branch is merged" to master, do you mean to do the merge, then arc diff that, then push the merge once done?

I thought that may be the case which is why I made sure I mentioned my pushing and my full workflow. I did read all the articles first, but they weren't particularly clear on the fact that you must not push or it messes things up.
In reality a developer may work on a branch for a small number of days (or more, though not ideal it does happen) before wanting it reviewed and merged, if they can't push at all during that time then it means they are liable to lose their work it anything goes wrong on their machine (which is not as rare as it sounds). Are you saying that no-one can push their feature branch to remote without also reviewing it? If so am I missing something because that sounds like it might be a problem for anyone who wants to work on branch for more than a very short period.
It is also a problem (and possibly a more severe one) when more than one person work on a feature branch, which is a common occurrence and allowed for in gitflow.

No worries, thought I'd offer seeing as I'm doing the work anyway!
A well written role can maintain idempotence even in the face of already installed and configured databases for example, and can work across multiple OSs (I am currently working with Centos/RedHat 6+7 and Ubuntu 12+14 for example) but you are right that it's a lot of work to do that, almost a job in itself, so I can understand that you don't want to have to maintain such thing unless necessary.

That worked perfectly, thank you.
I'm putting all of these configuration pieces into an ansible role which allows me to reinstall and configure phabricator automatically in minutes. It currently in an early state and I'm doing other things too, but I'd be happy to keep you in the loop on progress and hopefully provide it to you at an appropriate point should you be interested.

Ah, that'll be it then. I'm going to go from scratch this time and hopefully this'll be the last piece of the puzzle.
Thanks for you prompt responses and helpful information as always.

Ah, that explains it :)
I'm very close now, I've got a hosted repo and I can clone it, but when I push anything back up (authenticated http) I get:
"remote: error: insufficient permission for adding an object to repository database ./objects"
Apparently that is likely related to the groups/permissions of the repo directory. Any idea what I may have done wrong here? I'm scouring the net as I type though I've not found the solution yet.

I've just done a pull on all 3 projects (of course shutting down apache and phd daemons prior to doing this) and I did get some updates, however it unfortunately didn't fix the issue and I didn't originally install it more than a week ago which looks like it was after this fix.
I will restart the entire server when I can just to make doubly sure I've not missed something but currently it looks in my case like it is still happening.

That sounds great, and I totally realise that Harbormaster is in it's
infancy still, I just thought it worthwhile registering my interest in
something that I'd like to see. Feel free to close this as it sounds your
existing plans will make this request obsolete.

"and you're just trying to accommodate multiple projects which have some per-project meaning for the status"
This is exactly the case, this isn't for my own projects, but for the accommodation of any number of other projects that will have multiple definitions and meanings.

Unstable in jenkins is where the build completes but a publisher reports
unstable. In the case of a default maven build with JUnits for example, the
default JUnit publisher reports unstable if any test fails. I believe that
other publishers can do more complex things like mark unstable until
certain thresholds are hit and can then report fail for example.

Thanks for the info, I'll take a look into doing that in my case. If I do
get around to that then of course I'll post the code up on github for
anyone else.

I get your point, and agree, but I'm trying to service multiple projects, not just my own, and some of those projects will be very used to Jenkins and the unstable status, hence the request to be able to mark as such a status via the conduit call.
Also, it is useful to know whether tests fail or the building process files without having to go and look in jenkins, which I currently have to. It's really nice from an end-user point to get as much information as I can from a single interface/dashboard.
In an ideal world I would also be able to send back more information, such as a link to the unit test or sonar results page that has the fail. This would then display as a message along with the failed build. If this were possible then the idea of an unstable status is probably not useful any longer.

This would be great, agreed. As someone new to phabricator but a java person, I'm loving the apps, features and look the one problem is lack of compatability with the typical java stack (no real jenkins integration and no junit integration by default for example).
I wouldn't find this a problem if it was easy enough to figure out how to integrate these myself however unfortunately it's not and if the effort involved in figuring it out (or not) proves too great it's quite a barrier to adoption.

@bluehawk I've never done any php before but I took a look at the code and did a little debugging and realised the reason it's not working is that I'm not getting any task-add events from the tasks, only create. Create just immediately breaks in the swtich in BurndownData.php so I just got it to add the task to the sprint and it's all working now.
No idea if this will break something else or why I don't get the task-add event but it works well for me with that change.

@bluehawk I've got this running and it works well up to the burndown chart, which, while I have 3 tasks with story points in the sprint project, doesn't count the total points (see the screenshot attached).
Have I done something wrong here? You can see the three tasks but the graph doesn't show anything from them.
If the burndown chart was working this may be enough!

I've been looking at Phabricator recently and the lack of capability in this space is most likely a deal-breaker, however the screenshots you've posted (albeit rough at this point) look really good. I'm going to be grabbing this library and seeing how it fares for me as maybe this is a step towards unbreaking that deal-breaker :) I'll let you know how it goes.