Maybe a good idea too:
- What about if you can configure at owners, if the owners should added as (blocking) reviewers automatically? Makes this simple too.
Maybe a good idea too:
This one's slightly trickier than T10570 because leading whitespace is semantic in lists.
Thanks for the feature request! This feature request doesn't have the information we need to move forward, so I'd like to start by trying to understand why it doesn't. Specifically, it does not describe the root problem you are facing, and instead asks for a specific feature.
Ah, you're right, thanks! I misread that page -- that does make Mercurial tags a lot easier to deal with.
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), ...
Make it possible to add "subproject columns" in the parent's workboard
See T10333
Not sure if this is the right place to request for this, in an earlier build, the cards have username of the task owner on it, which is convenient to do a quick search using Ctrl+F to find tasks by a particular username. In the latest stable build, usernames on the cards are replaced with user photos instead, which makes Ctrl+F by username impossible. I understand that "Advanced Filter" is a workaround, but it is less convenient.
What version is libphutil at? This function was introduced in 821cad81.
Maybe that's how GitHub works. There is some discussion on D15432 on why that's not likely easy for us. I do want to clean that up and get a "Claim/Unclaim" action built for Maniphest though.
Interesting. I just went and tried it again and different times its failing in different ways. I'm going to give up and assume this is something wonky in my browser until I prove otherwise.
For some reason, I now look for a "quick edit" button on each of the fields in the right pane (like "Projects"). Maybe because they look bigger now?
Yeah, persistent details would be helpful. My best guess at repro steps from the screenshot is:
If you don't mind, can you provide specific steps to reproduce and attach actual photos to the task? External links can change/etc and we'd prefer to have a complete record. Thanks!
I'd also very much welcome an option to turn off colors, since they don't work very well in the Emacs shell.
T8887 is also related to this task
yeah it might be weird to have it be a tag, then be in the title. Maybe you're right it should just be [t/p] (total tasks/points) in a tag.
It needs a pile o' JS since it needs to change as you drag stuff around, but we can start with that.
pht(‘%s (%d)’, $title, $task_count);
I'm going to close this since there's no pathway forward that I can see. We might just not understand your request.
I slightly miss the card counts too, since we have points enabled on this install but don't really use them.
Hrm, I'm going to do some followup with our DBAs as well. The performance numbers above were copied from the DBA analysis; however, when I make the change in production, rather than in staging, some of the behavior does not directly replicate.
I'm going to write a CurtainExtension for it (I just missed it in the original round) but you might have to fix my bad stylin'.
Not sure offhand how to fix this.
I'll leave this open for now since the behavior still feels a bit spooky to me, let me know how things go once you get the key in place? If they're smooth, we can chalk this up to be being bad at MySQL.
I suppose the originally proposed key may be better than I think. I was imagining that it couldn't use the third part of the key (on changeType) but I suppose it actually can. I'm still confused by the UNION ALL behavior, but if the key's working on your dataset I think it's fine to add it -- it takes <1 second to add to our dataset, so even for large datasets it shouldn't be wildly unreasonable, even if we do find a better key later.
I'm seeing a replay of the (current?) rules about this message?
That's fine -- it looks like it's picking up the keys, I'm just not sure why it's then examining 303 million rows when it has the keys available.
to clarify: I removed the key I originally added
KEY `commitID` (`commitID`,`isDirect`,`changeType`)
was I not supposed to do that?
Hrrm, let me see if I can reproduce anything like that, that's totally bizarre to me.
KEY `cidid` (`commitID`,`isDirect`), KEY `cidct` (`commitID`,`changeType`)
are the keys created
id select_type table type possible_keys key key_len ref rows Extra 1 PRIMARY repository_pathchange index PRIMARY,cidid,cidct cidid 5 NULL 303320447 Using where; Using index 2 UNION repository_pathchange index PRIMARY,cidid,cidct cidct 8 NULL 303320447 Using where; Using index NULL UNION RESULT <union1,2> ALL NULL NULL NULL NULL NULL Using temporary
Hmm, weird. Can you show me the EXPLAIN SELECT ... for that?
That variant of the query is slow as well.
It's definitely a little surprising that "Outbox > Delivery" is describing a sort of hypothetical scenario that assumes you were a recipient in the first place.
Maybe we could add a "you weren't a recipient in the first place" reason which has priority over the other reasons, and make the text on the page more clear. Or just remove "Outbox" completely, I'm not sure it's really useful.
That is, "Delivery" is "delivery to you, the viewer". Maybe that's what's unclear?
The "Delivery" tab is specific to the viewer, not the mail. There's no way to see see why mail was or wasn't delivered to other users.
223663 is you adding a comment to Conpherence.
184911 is you moving a task on a workboard.
219192 is you attaching a task to a revision.
If I understand the mail visibility, you should be able to see 229037
(PHID-MTAM-qfsqnqkebrkuaohcacsg), because it's "to" you?
My last comment added 3 messages in my outbox:
I can't actually see them, let me go pull up the console.
I think all of those are not self-mail - they are all have "TO" as other users than myself.
In all of them, I'm the actor, but they specify "Self Mail" as the (a) reason for voiding.
I do have "self mail" disabled, so it might be taking that?