@MBinder_WMF: Also, under the hood you're saying that, since Wikimedia have multiple teams (multiple Tags) it would be nice to allow to change Task Points without interfering each other,

I've shared two proposals, that are actually requests for comments. I would be glad if some people could give a look and share a comment.

Thanks for the suggestion. Default-to-1 has been mentioned before, and it's not feasible because of teams that need to cross-tag, where some teams use Story Points and some don't (thus, 1 point means something to one team but another thing to another). It's also common for 2 teams to use story points but have different meanings, where 1 point is a totally different scale depending on context.

I'm very interested in this improvement.

Honestly, do you still like this Diff after all these compromises? :D

Having said that (string)$idx === (string)$selected seems legit to me, I'm not sure I can reproduce this issue before this patch.

@Ekubischta if you want to continue the discussion about the GitHub→Phorge bot, feel free to continue together here:

Having said that, in the meanwhile, as workaround, probably you could just - in few clicks - add "1" as Point in each Task. Then, use the Point Limit just as a "Count Limit" logically. If you would go for this approach, it would be great for you, because then you could ask the Wikimedia Foundation to, simply, assume 1 Task = 1 point by default, and I think that would not be a problem for anyone there. I say this since I want to suggest something quickly feasible for you, without waiting to reach consensus for a breaking change on everyone else in the Phorge world (which in any case maybe deserves a discussion).

I honestly think that adding a new feature called "Count Limit" on Columns would be useful for you, so that you can use Points Limit on Milestones; and Count Limit on Columns (and ignore Point Limit on Columns).

I see that you marked this as "Work in progress." I don't know how to highlight this fact, so I'm marking this as "Request Changes" (also because some changes were requested). Sorry if this puts a red mark, but I like this proposal of infinite executions of arc patch.

Thank you to @ncollins who helped me in understanding this topic, since I was not aware of this issue before today.

I also think that having the first branch called as arcpatch-D123_ (with trailing underscore) as default could be considered a breaking change by some users. I think this can and it should be avoided.

I tested this locally and it works, thank you.

FWIW even in the case the milestones are strictly ordered, it's incredibly inconvenient to sort out a situation where you need to add one to the middle of the list - forcing the user to rename a bunch of them to get things straightened out.

In T15082#2028, @golyalpha wrote:

epriestley was very much against this idea but wikimedia's users loved it.

Do we have epristley's reasoning as to why he was against this? Might help in deciding about including this patch in Phorge.

I like your assumption of good faith! I'm a little more cynical about the thoughtfulness of Phab development, and the thoroughness of features deployed. I'll try to follow your example. :)

In D25072#2285, @valerio.bozzolan wrote:

So the goal is:

• stop other listeners: that's why I've adopted stop()
• don't prevent anything: that's why I've not called prevent()
• don't open the pop-up: that's why I've set that return;

Shit - you was really fast

fix lint error "Line Too Long"

I noticed that, if you click on whatever other link while you are editing something, the Dialog is not show, and you just can lose your work.

Thank you @dcog for this Dialog confirmation that saves my day.

I don't think the hundreds of installations that use Phorge would want to abandon the way they do their thing so drastically. That is why I suggest to think about something that helps both them and you.

rename getPageID() to getMonogram() and add few inline comments

• fix

(I haven't seen @20after4 for a while now. Also @0).

• change language and replace "status" with "isHidden"
• celerify

Thanks for your help! Much appreciated that the attention on this is being raised. :)

So, if I have understood correctly,

Let's try to exclude some things. Are you sure that the phd is executing that file - just like the frontend? It happens sometime that some people has both Phorge and Phabricator and phd runs some files and the frontend some others. Are you using CentOS or any other distribution with SELinux enabled or this kind of security restrictions? Is there any security directive set in the systemd unit of phd? I think you are doing everything just right, but thank you for clarifying what you tried.

Hi! Thanks for following up on this. :)

Definition of the custom field that is queried:

Can you share a screenshot to this fact of... true or any but not false? Thank you so much

Its basically a predefined query that is called via conduit:

Thank you for this question. At the moment I think the answers are useful. I invite people in contacting you to give you support. In the meanwhile feel free to add more comments / reopen etc.

I'm marking this as resolved since I think the answer is useful. Feel free to share more comments / reopen etc. Thank you!

Feel free to share more details even if it's closed - we can alway reopen. Thank you

Feel free to reopen when you have more details