Can you change the syntax to something like @unittest.skip("Reasoning behind this decision...")?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 8 2017
That is, I think the right tool for the job is either runtime enforcement or lint enforcement: make unittest.skip() with no reason fail (so the tests don't pass) or make lint raise a warning like "unittest.skip() must have a comment above it explaining the plan for re-enabling the test.".
Can you change the syntax to something like @unittest.skip("Reasoning behind this decision...")?
I know about T9853, but if there's still a chance you might consider merging that upstream, there are a few folks here at Khan Academy who are excited by the feature. Here's one example:
Jul 7 2017
Jul 6 2017
This information may be entirely useless, but it is somewhat related. We have a large number of repositories, with multiple clusters so this affects us in a major way.
Have you actually tested this scenario yourself?
In T12901#228807, @epriestley wrote:Edit the Saved Query to contain something sensitive
This isn't possible.
Edit the Saved Query to contain something sensitive
In T12901#228799, @epriestley wrote:A user might have a saved query which contains sensitive information no one else should know about.
How would other users discover the query's ID?
From elsewhere:
A user might have a saved query which contains sensitive information no one else should know about.
Jul 5 2017
We've also had a request for this (disabling the in-application popups) at #dropbox, as a per-user preference.
Severely needed. .arcconfig should be able to control where things land without arguments. I also question the choice made in D10058 where branch tracking seems to be used as a indicator of a branch created with arc-feature. Since arc-feature is in no way central to arc use, I think it should not be assumed that it will be used. And regular workflows and GUI tools will use git-branch instead, with tracking.
Jul 4 2017
Jul 2 2017
Parsing hg export metadata is an elegant solution. # HG changeset patch could imply sourceControlSystem = 'hg'. Thanks for merging the task!
The background is the Mercurial community wants to try Phabricator as an experimental review system. It's using emails now. I'd like to make Phabricator workflow as convenient as traditional email workflow.
I'm writing a Mercurial extension to send changesets to Differential like hg email provided by patchbomb extension.
Jun 30 2017
Haha to be clear we're using an open-source self-hosted tracking solution, I was just throwing GA out there as an example. But I do understand your point vis-a-vis data security.
I guess everyone uses GMail nowadays anyway (as mandated by international galactic law) so my paranoia is probably mostly moot because they can undetectably read all email communication anyway.
I think you probably won't be able to answer most of those questions with Google Analytics. For example, bots will never hit client-side analytics, so any question about bots probably can't be served by GA. Likewise, GA can't see Conduit/API activity.
Why do you want to track users with Google Analytics or a similar library?
I think it's probably reasonable for us to warn about RSVP'ing to an event which has already ended. I'd guess this is usually a mistake, and in cases where it isn't some kind of weird off-label workflow is taking place and the warning is probably fine.
Jun 29 2017
Why do you want to track users with Google Analytics or a similar library?
in T6722#197239 I had the same problem with "land revision from Web UI" :)
Jun 28 2017
Thanks for this - suggested solution works perfectly!
Jun 27 2017
See T12874. Your account will be disabled if you continue creating tasks like this. Follow the instructions you were given.
/config/edit/translation.override/ then add the string, and what you want it to say instead. That's the quickest path here. Merging into the other request.
Can you be more specific here? If you just want to rename "LDAP Login" you can already do that with the translation framework.
Jun 23 2017
For (1), it's currently expected, yes. We don't create branches for dependencies in Git either, currently. I don't think this is terribly unreasonable, but I'm also not sure it's terribly useful (does it just help you keep track of which commits are part of the leaf?) and it makes cleanup more difficult by creating more total branch/bookmark artifacts in the local working copy.
For (1), it is expected to not apply bookmarks to dependency changesets that are applied as part of the patch issued? When patched one-by-one they would each obtain their bookmark.
Sorry, I should have led with a screenshot! I'm the biggest nitpicker, I know.
Some of the (3), (2), (1) stuff is that we're trying to pick a single behavior which addresses most use cases reasonably well. For example, if we use "natural" bookmark names that will tend to make things much worse for users in bucket (3).
Thanks, that's much more clear than the original description!
No they're not. I know it's a tiny difference, but look at this closely (left is my proposal, right is the current state):
I'm confused here -- the icons are already struck in every browser on my system (Safari, Firefox, Chrome):
Jun 22 2017
Jun 21 2017
Just to clarify, Phacility is the paid hosted version of Phabricator. If you installed Phabricator locally, we cannot help you with this request via Phacility. You'll need to follow Support Resources for your self-hosted installation.
Great! Please mail support at support@phacility.com and identify which instance you're paying us for, then we're happy to help you. We won't help you here, since this isn't the right way for customers to get support.
Yes,we are Phacility customer And I deployed it on a Ubuntu server,Thank you.
If you're a Phacility customer, please mail support at support@phacility.com (and identify your instance).
Jun 19 2017
Jun 18 2017
I was going to wait with updating this task until I'm finished but I'm stuck on GoCD side for some time. The extension for Phabricator is 99% ready so anyone interested may give it a try:
https://github.com/kszatan/harbormaster-gocd-buildstep
It's enough to be able to schedule a pipeline in GoCD but nothing more. This issue hampers my progress with notifying Harbormaster about pipeline status. I'll update this task when all is working as planned.
done! cheers
Jun 16 2017
Milestones works great for this, but you still have to manually create the workboard (just going into workboard and clicking create - milestones show up).
Jun 14 2017
I'm not totally sure about how/why users are expecting the behavior in the third case.
I'm not particularly strongly opposed to adding more options here, I just want to avoid the dropdown becoming this:
For the compliance case, you should already be able to trigger this stronger rule ("always add the package as a reviewer, even if an owner authored it") with Herald, by writing this rule:
As more of a point of philosophy of code review also, I (and, I think, my teammates) would say that diffs should be reviewed by someone who both:
- Understands the relevant code
- Did not write the code themselves
In other words, the combination of expertise + different perspective is of value beyond each component individually. If you believe that, then B or C should review A's diff in this case.
When you put it that way, it does seem backwards.
The use case in this task's description does not make sense to me.
We're interested in this option, since we find that users are often surprised by the existing behaviour. I think this would make sense as a per-package setting, rather than a global one.
It would be really nice to default newly added fields to hidden. Going through 20+ forms to hide the fields is tedious.
We do something similar ourselves for technical interviews, but I just related all the tasks by embedding them in the description of a central task:
I think this use case is a reasonable one.
Just discovered I could use the Milestones feature to do that. Will try this out.