I checked out Master and the behavior is still unchanged. I cannot even see any possibly related commits.

Hello @TechieNK . Cab you please, share a commit or branch or release, that I should check.

GR8! Thanks, Yaron!

GR8! Thanks Yaron!

I was able to fix it with a small patch. Unfortunately I am too stupid or inexperienced to follow the right process for submitting the patch. Thus I share it here.

I was able to fix it with a small patch. Unfortunately I am too stupid or inexperienced to follow the right process for submitting the patch. Thus I share it here.

I defined a couple of validation functions and successfully register them via

THX

They do give different lists of values, I was just verifying if the patch also covers the other case and it does not. As I wrote above, the valueList is properly fetched but later it is overwritten in setPossibleValues later with null again.

Thanks Yaron. I can confirm that the issue is solved for fields with the "property=..." annotation.
But for fields with "values from property" the list of values now is empty.
this code is executed and does the right stuff

$f->mPossibleValues = PFValuesUtils::getAllValuesForProperty( $propertyName );

But in setPossibleValues later it gets overwritten with null again.

I am using property=... which sets $semantic_property but none of the parameters to the later call to setPossibleValues. Consequently all three values are null.

After more analysis I found:

• since the reg-ex gets confused, the PFFormField in the PFTemplate has the wrong list of $mPossibleValues
• since I am using property=xxx the setPossibleValues function will choose the default case of $this->mPossibleValues = $this->template_field->getPossibleValues(); which will take the faulty possibleValues from the template :(

Hm OK, then sth. down stream is wrong.
As you can see the reg-ex thinks it is doing a good job but it associates the fieldNames ($matches[1]) with the wrong properyNames ($matches[2]).

Found the Problem. It comes from loadTemplateFieldsSMWAndOther in PF_Template.php

• https://phabricator.wikimedia.org/diffusion/EPFM/browse/master/includes/PF_Template.php$132

Yes, more or less. the template is quite big and I reduced for debugging purposes to the bare minimum. If you want a bigger picture it looks like this.

<noinclude>
Some text.
</noinclude>
<includeonly>
{{#ask:
  [[Categorie:SomeCategore]]
  {{#if:{{{Parameter1|}}}|[[Property1::>{{{Parameter1}}}]]|}}
  {{#if:{{{Parameter2|}}}|[[Property2::<{{{Parameter2}}}]]|}}
  {{#if:{{{Parameter3|}}}|[[Property3::{{#arraymap:{{{Parameter3|}}}|,|xxx|xxx| {{!!}}}}]]|}}
  {{#if:{{{Parameter4|}}}|[[Property4::{{#arraymap:{{{Parameter4|}}}|,|xxx|xxx| {{!!}}}}]]|}}
  | ?Property3
  | ?Property4
  | ?Property5
  | ?Property6
  |format=broadtable
  |limit=500
}}
</includeonly>

And in previous versions of PF this used to work as expected.

Hi Yoren,
the syntax is correct, because it is part of an #ask query. The part of the query will and should look like this

[[Foo::P1V1||P1V2||P2V3]]

After a couple of hours of debugging I find that the template from "for template" is relevant.

• Testing the above with a non-existing template works well. All fields appear as expected.
• Removing the content of the template works. All fields appear as expected.

@Aklapper I really have problems with the gerrit setup here. I followed the Gerrit-Tutorial which is partially good.

• But I had to learn where I need to put my SSH key the hard way :(
• I did it on phabricator and mediawiki but not on Gerrit, itself :(
• Further, the browsing support for the repos is really bad, compared to github and bitbucket :(
• I cannot use git-review thus apparently there is no way for me to push anything to anywhere ;(
• I cannot create a branch as recommended in the gerrit-tutorial :(
• I cannot use the patch-uploader "No existing author found with 'erdmann@diqa-pm.com'" ;(

I have a patch to fix this. But where should I put it and how?

We looked into this issue and found that apparently the error occurs, if we hava sth. like this in your local settings.

$wgGroupPermissions['*']['read'] = false;

Lockdown seems to assume that the anonymous user is calling the API and will check this uer's effective group, which will also be '*' and thus Lockdown will most likely block the access.