IMHO, that's more likely what you want in most use cases anyway. I can imagine
quite a bit of confusion arising if you modify a query for a dashboard and it
unexpectedly modifies what shows up elsewhere.

We could conceivably do something like "edit this query" link from the panel, and have that take you to /application/query/wzyx/?panelPHID=asdf, and that generates a "save this query back to panel X" option in the UI.

Hmmm, not sure there is any path here, I seem to recall we can't allow editing of saved search queries without generating a new key? And if we generate a new key, we'd have to find all the Dashboards it's attached to?

This sounds like the expected result to me. Even if they did get verified, they would immediately hit the same "No Access" dialog again.

well that was a waste. lolz. 🐈

I can't reproduce this with the steps provided. Here's what I tested:

You are my hero! :)

Also, really great bug report :)

Do you maybe have SELinux or AppArmor running?

Mine's fine here, too:

Only 5? I expected more.

Fair point, there was a bit of overlap, and the end result of a revision is super important (the commit).

Yeah we had both "commits" and "revisions", which had a bit of overlap. My main concern was if you were using this information to learn about a person, actual commits should hold more weight over temporal information like revisions.

Interesting, that decision makes sense to me.

(Commit-date ordering would also mean that forward-dated commits would be stuck to the top forever.)

That is, we order things by discovery date (when we learned about the existence of the commit), which is tamper-proof, rather than author date or committer date, which are freely mutable by the client.

If you just updated after more than a year, you are probably seeing imports from the change in T6878. Once those finish, things will settle down and "commits" will begin reflecting what you expect.

I believe there are plans to update it more than once a year at least

I'll take a look at the commits bug here shortly. Do you expect your install to keep more up to date?

Sure, apologies for the lack of clarity.

Or more specifically, I don't intend to add this back without spending more time thinking about the problem it solves. There are other possible solutions (including allowing installations to customize a user's sidebar) but in the context of doing a code review, I can't think of any benefit here. It's helpful for us to understand the entire problem you're looking to solve. If knowing a user's current revisions is important in the context of performing another code review, we'd like to know what that information is and why. What information do you get from it, and what decisions do you make differently because of it.

What is the root problem you are looking to solve? See Contributing Feature Requests and Describing Root Problems.

@epriestley, I tested out the scenario with the change applied.

I apologize, just this error is so floating that I still can not understand at what level it is. Now I come home, I load the picture - and it loads well enough.

Downgrading accepts and rejects (changing "Accepted" into "Accepted Older") uses raw edge transactions.

The Herald case and the next case (newAutoReviewTransaction()) both have some code duplication around prefiltering reviewers before building transactions for them.

Instead of using open registration, can you invite users instead and immediately add them to spaces so this doesn't happen? Why are you allowing open registration if all registration must be coordinated with an administrator anyway?

This is vaguely involved.

It sounds like this is resolved.

We don't plan to take any other upstream actions here, but let us know if anyone has further questions.

Please provide complete reproduction steps the upstream can follow as well as your installs version information. This information is required before we accept any bug report. See Contributing Bug Reports for more information. If you'd like a clean environment to test in, please use a test instance at Phacility.

No, it would not.

@avivey: I'm somewhat interested in this if you have any tips for getting it working locally I would like to try it out and see if I can contribute anything towards a finished extension.

Thanks for the hint!

For example, just try to load few times this file from our webserver.

Any resolution/guide how to avoid that obstacle ?

Still facing the problem with Locked task in any new task created. Even on new install. It's database/app config. Please guide where to check about that "locked task" flag BEFORE is created object.

See T10038: Plan the mid-term pathway for unit-test/linter bindings and Community Resources.

This should now be fixed in HEAD of master. I've also cherry-picked it to stable. Thanks for the report!

I think this commit in the Git upstream is probably the culprit (January 2016):