Can confirm this is fixed. Yay!

@epriestley, what's weird is, I still have this on my bug install, despite having the latest stable updates. I checked, and the migration definitely ran. Thoughts on how to debug this further?

Well, crap, we were actively relying on this. Even had a new Conpherence integration created.

@epriestley, I tested out the scenario with the change applied.

Ah! That fixed it, thanks @epriestley. I'll let you know once I test out that configuration.

@epriestley, I wouldn't mind testing that scenario out this weekend (I'll have to change a couple of domain name settings to create the scenario, but that's easily undone).

Yep, D17429 fixes it! Awesome-sauce. That's exactly why I didn't file the bug report yet - I'm on stable, so I can be about a week behind.

Hey, the Chatbot is now refusing to start up since I pulled in the update with this commit. Here's the cursory stack trace:

Thanks @epriestley and @rfreebern - your scripts worked perfectly! Between them both (and tweaking that one "hasSubprojects" field in the database myself), I was able to move an entire project tree. Yay!

For what it's worth, I haven't seen the problem I described at all recently. It must have been resolved (or there was a ghost living in my server...which I'm starting to suspect.)

@michaeljs1990, is was actually not possible to install PHP5 on Ubuntu 16.04 through a safe means (an apt repository or similar) for some time.

@PascalReintjens, correct, in the same way that it won't run under Ubuntu 16.04 (which also comes with PHP7 only).

Awesome, thanks @epriestley. The update cron script runs that bin/storage upgrade every time.

I definitely agree that in most cases, 100+ subtasks (especially direct subtasks) is better as a project. Still, I think it would be pretty simple to just shut off the task graph (but not the list?) in those situations if there is an exception that hasn't been thought of.

@epriestley, just thought you'd like to know that, on that aforementioned massive task, the task names are now entirely missing. If you scroll all the way to the right, it shows the assigned person, and that's it. :\

@epriestley, I'm not expecting any particular solution, just as long as the list of subtasks is navigable in some sane fashion.

@epriestley, the use case is actually from my content development department. It's hard to explain the task, but the hundreds of direct subtasks was unavoidable, and the project workboard did not work well in their workflow. Developing content for educational software can be extremely demanding. That said, I'll admit it isn't common to have hundreds of subtasks. Still, it is a scenario that can happen, so the UI should still look good given that edge-case.

Confirmed workaround: set base project edit permissions to something other than Project Members.

@sascha-egerer that would seem to be the main factor, and the reason this couldn't be duplicated initially. It isn't all milestones - it is specifically milestones for projects that have subprojects.

I know this was linked against my question, but I wanted to check and see if it is the same thing...

@epriestley, ah! I get where you're going now, though I'm not sure why I missed it before. *Sips more coffee.* Sorry.

Apparent temporary workaround if anyone hits this because they upgraded to Ubuntu 16.04. Not yet tested (since I'm still on 15.10 right now), but I have confirmed that the package repository in question is live and contains the proper packages.

@epriestley, oh, *THAT*. When people are running Linux servers, Ubuntu actually is one of the leading distros because of the ease of setup and use. According to w3techs, nearly 32% of all Linux servers are running Ubuntu. It's second only to Debian.

@epriestley, he's right, see the official Ubuntu 16.04 release notes. More info here and here.

@chad, I've updated the title to reflect the updated (and confirmed) duplication instructions. The specific problem is that, if a project has subprojects, then any milestones belonging to the base project cannot be modified.

BINGO! We have duplication. The updated steps in the description *will* recreate the issue.

@eadler, how do I do that? EDIT: Nevermind.

@chad, I updated the reproduction instructions. I think the project having Subprojects already before adding the Milestone might be the mitigating factor. Let me know whether that reproduces. If not, I'll dig some more until we get this thing reproducing. I swear it's there!

Is is a mitigating factor that the PawLIB [Project] has six Subprojects? They all work correctly. I didn't think of it at the time, but maybe that has the project membership subtleties mixed up.

Oh criminey, that should have duplicated. Those are nearly exact same steps I followed on my local copy, but I get this:

A multitude of thanks for this!

I'm on stable, so this hasn't hit mine yet. Is there a particular way to patch this in without switching branches, or can it be promoted to stable (thereby stabilizing stable?) Sorry to be a hassle. It's one of those days. >.>

(I got an error when I created this bug report, which is why I went and added another one. Then, I discover they're BOTH in existence. Meh. Merged duplicate into T10766: Calendar - Unhandled Exception, since I referenced that task elsewhere.)

Hi @chad, okay...that's creepy. I had the error on this server when I tried to submit the bug report a little bit ago. Now submitting an identical report, it's gone.

This is the last update to hit my server, and now both here and there...

Also, to directly answer your question, the existence of Schrodinbugs and Heisenbugs suggest otherwise. ^,^

Hi Chad, I had to try commenting on a file to test if a bug on my server was present here as well. It is - see T10750: Cannot Edit Comment on Files.

(This is a test, to validate a bug.)

Ah, I see. Well, that's one more way to solve it, I suppose. At the same time, it might be slightly less efficient if you have to do that on 20-30 objects in one session, and then edit. The hammer method would be one command and one login, and then you can edit all of the above (including policy, via normal web interface means.)

Hm, somehow I missed the documentation on that. However, set-policy does not work on all objects.

Added several scenario issues to the description. I don't know that I can track down all the comments, as this place is huge and my memory is pretty shaky on things like that. I just remember a observing few different conversations regarding it, but I cannot remember where. If we polled users, we could probably get a better idea of whether this matters to users in general.

Right, yeah. CSI is somewhat separate, since most of it isn't intended to be picked up by autodoc tools, but it is also designed to not conflict with those. (I should have the published standard up on my site in the next week.) Docs are "what does the code do" and "how do I use it", CSI is "why is the code like this and what is it doing?"

I'll admit, his docs are quite impressive. What I'm referring to is effectively inline-documentation of the code's intent itself, which is inherently separate from docs, and is solely to make maintenance by any programmer who takes the code on possible, without involving the previous dev in person, and largely without invoking the consequences of Brooks' Law.

I'd have to agree not to write things twice. That said, I do know that when we undertook starting our own animation system, we first dismantled the open source one we were considering prior (that's where we commented everything), and figured out the inherent problems at its core, which in turn prevented making the same mistakes in our system. Plus, some approaches may be at least partially salvageable for v2, tying back in with the basic idea of "don't code things twice".

Right about now, it might be worth mentioning that my company instituted a standard of commenting every single logical statement in code, stating the intent of the logical statement (not just restating the code).

Yes, I know. I also know bugs can get buried or resolve themselves over time (seen both), so since this is a bit old, I'm just confirming on stable for reference. Take your time. :)

Confirming that this bug is still kicking in the latest stable.

Just a heads up, this looks to be resolved. I've changed all the projects to only have future-valid hashtags, which usually involves my renaming the project to remove the [ ], and then, renaming it back, thereby forcing the automatic hashtag to regenerate properly.

I can confirm this as well. (I also tried to find where this was to fix it...couldn't locate it. @epriestley, if you point me to the file this bug would be coming from, I'd love to tackle this.)

Ah, I just edited because I realized the difference b/w hashtag and title. I don't like punctuation in hashtags anyway, so all's well. :)

I don't mind DCing use of [] in the title, if that's what you were saying we should do...forgive me if I misunderstood. If so, I need something to use as a replacement. We have projects that are Teams, Projects, Departments, and Groups, all which need to be easily queried, and all of which need to be obvious where they belong. Right now, I'm saying "IMF [Team]", "PawLIB [Project]", and so forth. Just saying "IMF Team" or "PawLIB Project" looks entirely too messy and disorganized for our use.

Just a heads up. I hope those duplication instructions are sufficient - this is a very weird one.

After extensive testing, with help from @avivey on IRC, we discovered this actually wasn't caused by a deleted user - that had cleaned up just fine. It appears to be a new Projects related bug. See T10168: Provide a clearer pathway forward for old projects with invalid hashtags.

Hm, I attempted another reproduction of the issue on a clean repo, and I can't get it to happen now either. Perhaps something didn't get the memo when I untracked some old binaries in the other repos. GA and mark this as invalid, I suppose, and I'll update here if I pinpoint a problem. Thanks anyway. :\

Aih, I'm having one of those days.

Hmm, okay, I wrote those out in list form to make it a bit more obvious. I don't have any way to try and duplicate that here.