Psyduck is the greatest pokemon of all time.
- User Since
- Feb 8 2011, 1:28 AM (310 w, 3 d)
We could definitely integrate this into MenuItem (at least, if Home is staying wide? Maybe not if it's collapsing like Projects?) but ideally maybe no one notices or misses this stuff.
Maybe even some CSS!
I think we can get rid of a lot more stuff, like DifferentialApplication->loadNeedAttentionRevisions(), PhabricatorApplication->loadStatus() and callsites, the entire PhabricatorApplicationStatusView class, the stuff in People, Phrequent, Maniphest and Flags, probably some strings in USEnglishTranslation if you want to get ambitious, and the MAX_STATUS_ITEMS constant. Like seven million lines of code.
I'd be happy to, see Consulting to move forward.
How do I reproduce unexpected results at the application level (for example, what's something I can search for that doesn't match but should match)?
Yes and no. So: maybe?
The !== null also catches this bug:
I think this is reasonable to have even if we rename since it costs us ~nothing and adds some flexibility. I think broader renaming is still on the table; we could do "light" renames, like one of these:
While I've got you, how do you feel about a diff to:
(If there's pushback, maybe like a "one-time hacky copy your old global app settings into the menu script that we don't support" sort of thing? But I'd guess users won't feel like this is too painful since the new menu is a lot more flexible/powerful.)
I think it would potentially be reasonable to not migrate, especially if you do another blog post like the Favorites one to ease migration pain. Global stuff is relatively recent and pretty easy to put back in place, and I think a gentle nudge to configure the menu to work well for your install isn't a bad thing.
Maybe less complainey now that Audit and Differential have fairly sane default "stuff you should do" bucketed queries which can go on a dashboard? But who knows. I tend to think we should make an effort to toss these and see how much pushback we get. In particular, they're very expensive to build relative to their utility (and no one has complained yet that I nuked the Audit count, although it has only been gone for a little while).
Sounds good. I'm going to close this since it doesn't seem to be moving toward becoming a bug report which we can accept upstream.
There's a TODO about this in the code:
I'm going to merge this into T12134, which begins defining a more concrete plan roughly following some of the outline above. The major change from an upstream perspective since this task was filed is that we have a more specific set of harder technical requirements around support for Phacility SAAS instances (particularly after the launch of free instances), so it makes more sense to let those requirements drive product design and then accommodate general free support under that umbrella. Broadly, I expect to move support (bug reports, feature requests) into Nuance and continue reducing user access to the upstream.
(This change was half-accidental, and then I just figured I'd roll it into T2393 when I realized I'd made it.)
This did actually change in connection with T10978, but only if audit.can-author-close-audit is configured. I plan to resolve T2393 (maybe today?) and hopefully get rid of "Close" and this option entirely. I'm just going to merge this there.
I'd be happy to work with you one-on-one to help troubleshoot issues in your environment, but we can't offer that kind of support for free. This process almost always takes up a large amount of our time and very rarely uncovers any real bugs in Phabricator or helps anyone except the single user experiencing a configuration problem. See Support Resources for more discussion of the kinds of free and paid support we offer. If you'd like to move forward with one-on-one configuration and environment support, see Consulting.
Thu, Jan 19
I am unable to reproduce the issue you described by following the steps provided. To move forward:
Here's what I did to try to reproduce this:
This only controls the UI, I can counterdiff you for actual validation logic. I think there's an existing TODO on "Link" items anyway since they have no validation on typing garbage in for the link target, which can be confusing since security code then nukes it on the display side.
You could, but it's enough work that I don't think it's worthwhile until we do a general update here (maybe related to generally improving logging/security stuff?), since "Disable / Enable" isn't transactional right now.
I'd like to fix this timeline to show administrative events, particularly account disables/enables. This information is indirectly available in People > Activity Logs but inconvenient to access. However, I can put the timeline back after I fix it.
(A synthetic repository which you create by running hg commit in a loop, or instructions which allow us to build such a synthetic repository, are also fine.)
An existing, open source project is perfectly fine, provided you first verify that it reproduces the problem.
We need specific reproduction steps to move forward, and "a repository with about 2800 commits" isn't sufficiently specific.
This is easy but I think you want to get rid of all the IconSet stuff and just let everything have any icon?
This report is probably correct and the remedy is likely also correct, but getting lint into Diffusion is completely in shambles so I'm actually not immediately sure how to reproduce it, at least in a reasonable / moderately-convenient way.
Yeah, non-admins editing their own items.
Not intentional -- @chad, I can figure out what's going on there since it might reasonably be me and I have a local repro.
Wed, Jan 18
I think the big trick on this is going to be making inline comments work somewhat-correctly in the extreme case of octopus merges.
Does upgrading past b21cd24341c6552a3fbd21305ca682a161129a6b resolve it?
As an adversarial actor, I can use the proposed rule to avoid audit of dangerous changes like this:
My merge of T6557 here was questionable, but I think this is a case where the audits are basically correct and the remedy is better cleanup tools.
Sounds good, thanks.
Per above, not sure how to reproduce this.