Psyduck is the greatest pokemon of all time.
- User Since
- Feb 8 2011, 1:28 AM (320 w, 14 h)
In fact, I'm pretty surprised that your workflow doesn't hit major bugs/issues all the time, unless this stuff is currently far bugger than I believe it is. If you ever tag "Project Y" before moving a task to "Milestone 3", you'd no longer be able to move it from the workboard since it would vanish (until T11036)? Do you have a very specific sequence of organizational steps you take to avoid these issues? Are you just not using workboards at all?
(And, unless it's also bugged, I believe moving from a milestone to a non-milestone column on "Project X" should already strip subprojects. The proposed behavior just prevents there from being any subprojects to strip.)
I agree, I don't think project tags should ever be automatically removed.
No, I don't mean that, as written.
This has been out in the world for a little bit without exploding. I'd like to maybe do a bit of UI touchup but that can happen after T12272.
If you believe you've found a bug in Phabricator, we need all the information discussed in Contributing Bug Reports to move forward. Specifically:
I believe the expected behavior is that "milestone, subproject" kicks the task out of the milestone (leaving it in only the subproject) while "subproject, milestone" kicks it out of the subproject (leaving it in only the milestone).
I'm going to close this because I think it no longer meets the modern requirements for a feature request (it was filed in 2012). In particular, I don't understand why this is a problem:
The workflow thing is somewhat nontrivial. Previously, we would explicitly downgrade "Accept" into "Accepted Older" when an author used "Request Review".
Just as a general workflow suggestion, I'd encourage you to do this as a bunch of small changes instead of one big "fix everything" change: I'm completely happy to review very small changes (e.g., just remove code with no callers; just do text fixes; etc). I'm also planning to help with T12450 myself and getting small pieces upstream sooner makes that easier in terms of testing/conflicts. It's completely fine for T12450 to end up with like 20 revisions attached to it, and I think this generally makes all the review/coordination/release/project management type stuff easier (and, at least for me, the engineering stuff too).
From T10967, there's a minor workflow issue with "request review" incorrectly putting accepted changes back into an "accepted" state from this.
20after4 requested review of this revision.
This revision is now accepted and ready to land.
THANKS FOR RUINING THE JOKE EVERYONE
If you fullscreen, then click "Upload File", do the masks get screwed up and/or stuck?
We need reproduction steps to move forward. See Providing Reproduction Steps.
so it's tokenizing maniphest.query as two separate tokens
Sun, Mar 26
It probably should -- you could always write \\n if you really wanted a literal backslash + n -- I think we just haven't hit it before.
I don't plan to implement the original feature as described.
We haven't seen significant additional interest in this in more than a year. I expect to implement T7860 but, not a query microlanguage.
This was tagged ElasticSearch and may now be resolved (see T12450) but also lacks information we require in a modern bug report (specifically: precise reproduction instructions). If this is still an issue at HEAD of master, feel free to follow up on T12450 or file a new report with reproduction steps.
I'm just going to close this in favor of T12450.
As a general product decision, I do not expect search to be substring search by default -- searching for pricot on Google does not match documents containing apricot. But we can sort this out in the long run.
One minor inline.
In terms of figuring out which repository your working copy is, what does arc which show?
Sat, Mar 25
These are now up to date.
I'm going to presume this is approximately resolved.
But if you say "Haskell" you may have to wait a minute.
Maybe easier would be for you to tell me what language you want to use and I'll just write you a snippet which encodes a request?
The page implies that all I should need to do is POST up, for example, the following:
Fri, Mar 24
(In the longer term, the permissions here could probably be cleaned up, but I think that's the cleanest fix without upstream changes.)
You can edit the "Create Form" form and change "Visible To:" to "Members of Project: Doctorate in Form Theory". Then only members of that project will be able to create other forms or edit the form form, I believe.
Ah. I think you'd just see this, then:
Overall, you only get checkboxes for users, packages and projects which are already reviewers, with the exception that you'll get one for yourself if you aren't a reviewer yet.
I think there is also zero legitimate reason for the form-configuring-form to be editable and this entire workflow essentially represents a trap for the unwary.
If you can't enable that form, you might need to go hunt it down in the database and manually enable it (or tell me what you hit and we'll fix it if it's a bug).
Can you click that link, then "Enable Form"? Or do you get some kind of error?