Now i have changed that
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 29 2017
In case anyone is still looking for a Trac Wiki -> Phabricator Phriction importer, we have an ugly but mainly functional script I pasted here: P2056. Code blocks are not always converted correctly, but for us that script was enough.
In T12766#225295, @epriestley wrote:Also, test agents probably shouldn't be accepting revisions at all. But ¯\_(ツ)_/¯
May 28 2017
@epriestley, if you had any thoughts on this it would be appreciated as this issue is heavily affecting our users. There is a workaround (update our .arcconfig files to point to the new domain), but we have a lot of repositories...
Thanks! We'll keep this around and see if a migration is needed. Sounds like mostly a dashboards issue.
@exp10r3r you still need to provide reproduction steps. Based on the ones provided, I cannot reproduce any issue using a new/clean install on Phacility or locally. That doesn't mean there isn't a bug to fix, but without the specifics needed to observe and troubleshoot the issue, we have no idea where to start or what to look for. Because we provide support for free, it's on report submitters to fill in all the details needed here. We can't assist with that. No other install is reporting this issue, so it's unlikely due to any change from the upstream.
Can you just pick a new query and fix the panel?
Can you just pick a new query and fix the panel? My thought is if only 1 person in 12 months is affected, it's going to be faster for you to fix the panel than for us to find resources to build an old image and test migrations.
I can confirm T12129 is indeed related, and the suggested workaround is very effective. Thanks for this!
For the record, our repo has about 60 branches total (about a dozen active only).
Took another pass here. I'd still like to figure out a way to get and working, but I could also just design them into the comments like they previously were. I think it's better though to have them in the top bar, since I could click on the and get right to the first bit of work I need to do.
(though we could add a mini-minimap to it, just a thought)
(it's probably distracting and pointless though for code review)
To be clear, the "progress bar" background was a simple scroll indicator, nothing related to marking things done. Some blogs use them and I find in ... interesting ... nothing more. It's sort of nice to know how much you have to read through to be finished. It would start at the top of the first file and end when the final comment box appears. You can see one in action here: http://www.avclub.com/article/why-does-superman-keep-getting-turned-dictator-255977
May 27 2017
I'm going to merge this into T9846 since I think they're the same, yell if it looks like I'm missing anything.
Thanks, everybody! Appreciate it, especially on a Friday night. :-)
Based on two points of anecdata so far, things indeed seem snappier with D17959.
Please read and follow Contributing Bug Reports carefully.
Here's an example of the old style:
Also, test agents probably shouldn't be accepting revisions at all. But ¯\_(ツ)_/¯
Note also that differential.revision.edit accepts IDs and harbormaster.createartifact allows you to create links to build results without needing to gum up the feed with comments. We will eventually remove differential.createcomment so things will need to update sooner or later.
This should be fixed in HEAD of master and stable. Thanks for the report!
Its on another page for scalability, we used to just have a single page.
Yep, that would be the page. I was expecting to see details ala "Related Objects" in Maniphest and failed to move my eyes sufficiently left.
This page?
That does indeed work! Thank you so much!
Does this work?
Not easily. :/
In T12234#211222, @epriestley wrote:From a technical standpoint, we did not record these relationships in a normalized way prior to D16196 (June 2016, about 7 months ago) -- they only existed in the transaction log, and we just wrote a "close", extra_data="as duplicate of X" transaction that can't be queried efficiently.
Can you use the modern conduit calls?
May 26 2017
This accidentally got fixed this week
That looks great to me.
Actual example output:
Yeah, with whatever wrapping context maniphest.search has, so like:
So should the return value for priority.search look something like this?
That is, the specific error "use lists" is aimed at preventing is this:
The config also looks like this right now:
I guess we already have "keywords" and should probably accept any of them, too, so "!priority high" in mail, /priority high in a comment, and "high" in Conduit all work consistently even if the actual key is "elevated".
Ideally, we should maybe freeze maniphest.querystatuses (which has a sort of ridiculous output format, I think?) and provide maniphest.status.search and maniphest.priority.search, which return results similar to other modern *.search methods even if they aren't implemented quite the same way (at least make the output format similar enough that a client library with methods like "turn a x.search call into a list of objects" would work on these methods, too).
It looks like what we really need is a new method like maniphest.querystatuses, called maniphest.querypriorities to avoid anyone trying to hardcode these values.
That sounds right to me.
Specifically, reproduction steps are a set of complete, detailed steps we can follow and see the same issue you are seeing locally. Bonus if you've taken a new, clean image and reproduced the issue.
This bug report is missing version information and reproduction steps.
This looks pretty easy. No mentions of DifferentialDraft in the codebase other than the class itself and a single migration. Steps here (I think) are:
See Planning for information on timelines and priorities.
Just curious if there is any news on this front?
Anyways, let's just go with "See all" in the header for now.
I'm also not sure how that works with pagination, like, do you update the URL so people can send links?
But that sounds like a lot of work.
Basically what I'd like is something that auto-pulls maybe 5 times, then just makes you click a button thereafter. That solves the footer issue, makes it nicer for people who only want 2-3 more pages, and then the edge case of "no really I want to keep reading past 500 results" have to click a button.
Let me marinate on it.
Sure, we can do that too.
Isn't auto-scroll with lots of JavaScript the right answer?
Ah, that makes sense. If there's some "good enough" way to get a button/link into these things today I'm happy to drop that in place while I'm in here, but we can just leave it for fiddling later too.