Thanks, Chad. I've just used the Administrators group and adjusted the EditEngine permissions, which is sufficient for us; anyone authoritative enough to create blogs is authoritative and technically proficient enough to have admin privs, too.

Please see Contributing Bug Reports for what information is required for bug reports.

On the right side in actions

(not building locally anymore, eg, any time I want to do anything with a built binary at all, i'm actually doing it with a binary on a remote server because I can get the build results faster)

Well one facet of this is that remote servers tend to be significantly more powerful than developer machines, and so since I've implemented this downstream, I have basically taken to not building locally anymore.

In T8135#195971, @chad wrote:

@olivier-squid is the main issue people don't know it's going to happen, or that we just get it wrong. Will the headers help or are you expecting this to just not happen at all when you drag (ie, no sort changes happen at all).

Yeah, it makes sense to not auto-subscribe and I'm afraid I don't have better plans ready for cases where you don't want everyone creating blogs. You could at least make a group like "blog creators" and delegate.

+1 it's very confusing

Do you have any use cases which are not approximately some flavor of:

Maaaybe Iam misinterpreting but if enabling sort by priority why not show in workboards something like

@olivier-squid is the main issue people don't know it's going to happen, or that we just get it wrong. Will the headers help or are you expecting this to just not happen at all when you drag (ie, no sort changes happen at all).

I mean, it's probably not worse-worse, and but it feels like trading one kind of confusion for possibly-moderately-less-confusion more than putting a reasonable stopgap behavior in place until we can fix it properly.

Oh. To me, that's sort of worse? You end up with "Sort by priority" and your tasks aren't actually sorted by priority if you've moved them between columns, and jump around if you reload, and other users won't see the same ordering if they're trying to follow along in a presentation or whatever.

I think I'm doing a bad job at saying that though.

I'm suggesting removing it until T10333

Sorry, I think I'm still not understanding. When the column is grouped by priority, I still expect the auto-reprioritize behavior to work more or less as it does today: if you drag a task into the "High" group, it will change to "High" priority. I don't think we can avoid that without greater confusion.

I assume "Group by" would have dragging support, so by assignee, I could easily re-assign tasks. With that in mind "Group by" and priority, you could drag and drop by priority, thus allowing us to remove the "automatic" feature we have today in the current priority sort.

@chad Oh, maybe I'm misunderstanding. What are you proposing, specifically?

I think my question is, maybe noone wants this feature.

I think of T10333 and what remains here as mostly the same task -- I don't plan to make sorting and grouping separate (offhand, I can't come up with much of a good reason to group + sort, and if we did support that it would recreate a small version of this problem within groups).

@chad, T10333 may address this, but looks very complex for a very simple issue.
Believe me, everyone using phab in my company complained about the priorities being automatically changed.
Sorting by Priority is a very common/natural way of using boards.
You should at least propose a setting in Phab to disable this feature - this would make everyone happy.

Natural sort is the default. If you switch sorting by priority, then this feature comes up. The only thing left on this task (since natural sort is now the default) is implementing a UI around the drag and drop for clarity. T10333 is that task.

It isn't the default.

Hi @chad , I'm talking about this issue : "drag & drop on a workboard sorted by priority behavior is surprising" which I understand to be the scenario where you move a task form a column to another in a board and if you're sorting by priority the task might have its priority changed depending on where on the column you drag it.
This behaviour in completely insane - I understand that someone may have thought of this being a shorthand - but it's a very bad idea to implement this behaviour by default.
Apart from this, Phab is awesome.

I consider this mostly resolved. Can you open a ticket with complete steps to reproduce per Contributing Bug Reports if you are still seeing issues. I honestly have no idea what "nightmare" or "here" means.

Could you please raise the priority of this issue? It's a daily nightmare for all folks here.

I used to think this way. After all, in an extreme programming environment it is common for two people to be working on the same task at the same time at the same machine.

testing

Sorry, apparently after running arc upgrade it no longer times out (although it does take a long time).

arcanist(head=master, ref.master=8f69a5c378c3), flarc(), phutil(head=master, ref.master=ff84abc7d857)

In T11699#195930, @chad wrote:

The error log says July

The error log says July

Server

• rP38b10f05a224d29c723c033dec0820f977aa8026
• rARC483e985d08d279816708a9e755de8e5c3586d3ba
• rPHU1a0371a2247a256d1e6e44d4f348adc2750a9788

version info please

Here are some query traces from XHProf:

I'm following up with the one who reported this to me.

hghg

[[ http://[url=http://www.test.com/" onmouseover="alert(document.domain)" ]http:="" a="" "[="" url]"="" target="_blank">http://[url=http://www.test.com/"/onmouseover="alert(document.domain)"/]http://a/"[/url] | name ]]

name

[[ http://[url=http://www.test.com/" onmouseover="alert(document.domain)" ]http:="" a="" "[="" url]"="" target="_blank">http://[url=http://www.test.com/"/onmouseover="alert(document.domain)"/]http://a/"[/url] | name ]]

aman

http://[url=http://www.test.com/" onmouseover="alert(document.domain)" ]http:="" a="" "[="" url]"="" target="_blank">http://[url=http://www.test.com/"/onmouseover="alert(document.domain)"/]http://a/"[/url]

name

I can't reproduce it anymore I'm afraid. Before I posted this I tried deactivating the repo, disable/enable the URI to no avail.
After I posted I removed the repo from the command line and recreated it from scratch. It now works. All the details are the same (I'm using a private key).
Works fine now
-\o/-
I've added other repos, observed and hosted (public and private) since posting and they work too. I don't know what caused this to happen on the first repo I created but I can't reproduce it since doing the remove.

Not sure how this was set up, but I noticed this in the logs.

How can I reproduce this locally? See Providing Reproduction Steps for help on providing reproduction steps.

Found something to reproduce this problem, or at least, I assume that plays a big role in it:

Our actual internal use case is as follows:

To accept this report, we need reproduction instructions we can follow to reproduce the issue locally. See Providing Reproduction Steps for details.

I would like to be able to do this as well. Being able to update a Phriction document.

I think this is entirely reasonable.

My concern here is the specific request only solves a side-effect of the root problem, and not the root problem itself.

To actually add a remarkup rule, the basics are simple:

Actually, the problem seems to be in the system configuration. There a hard limit on open file descriptor ( which limits mysqld to 214 connections.