Page MenuHomePhabricator

namespace has no effect when values_from_concept values_from_category are used
Closed, InvalidPublicBUG REPORT

Description

Steps to Reproduce:

When setting namespace for a field and using autocomplete with values_from_concept or values_from_category.

Actual Results:

  • The namespace parameter is not passed to the API call
  • The namespace is not appended to the autocomplete term

Expected Results:

  • That the autocomplete term be prepended with the namespace
  • This even though this might implicitly filter out values from within the concept or the category.

Event Timeline

Also applies to values from namespace

@Yaron_Koren , I was just about to report something along the same lines - the documentation specifies we can use the "namespace" param with both combobox and tokens input types, but only the combobox has code to handle this - combobox_proto.onChange in ext.pf.select2.combobox.js.

A (should-have-been-obvious) workaround is to use values from category= instead of values from namespace=, but it does lack elegance.

Sorry, I think I missed this whole bug report before.

I have to confess, I didn't even remember that there was a "namespace" parameter for some input types - I certainly don't remember adding it in. This seems like a silly question for an extension developer to ask the users, but: what is the point of the "namespace" parameter? Can't you just have the template prepend that namespace onto every value?

Actually, you're right - it could be done through the template.
git blame says you checked this in back in 2016, "Based on a patch from
Simon Heimler" (gerrit change 288625 https://gerrit.wikimedia.org/r/288625).
It looks like the entire tokens onChange function was removed at some
point, likely during the Select2 library upgrade, and so this change was
lost there.

While this isn't really needed, it's already in the code (and documented on
the wiki) - which of the following do you think we should do?

  • break b/c, remove this and document the "workaround"
  • Remove the documentation claiming this works for "tokens"
  • Re-add the missing code to tokens

That's very interesting - thanks for looking that up. My instinct is to go with the first option - remove the "namespace" parameter, since it doesn't seem necessary, or even all that useful. On the other hand, maybe there was some specific reason to add it, which I've forgotten now. Does anyone here really want this feature preserved - and if so, why?

Reedy renamed this task from namespace has no effect when values_from_concept values_from_category are used to namespace has no effect when values_from_concept values_from_category are used.Jun 18 2020, 6:34 PM

That's very interesting - thanks for looking that up. My instinct is to go with the first option - remove the "namespace" parameter, since it doesn't seem necessary, or even all that useful. On the other hand, maybe there was some specific reason to add it, which I've forgotten now. Does anyone here really want this feature preserved - and if so, why?

On our wiki, we use the namespace parameter to provide a combobox that lets an editor select a user (by fetching all the pages in the User namespace). Then again, we could replace this with value_from_concept.

However, SMW does not seem to be requirement for PageForms. Removing values_from_namespace would make it so in this use case.

To be clear: I'm talking about the parameter called "namespace=", not "values from namespace=".

To be clear: I'm talking about the parameter called "namespace=", not "values from namespace=".

Yes you're right. The PageForms manual states that for the tokens input type:

namespace - Prepends the specified namespace to each selected value

This breaks my setup, as now users have to enter User:User_Name rather than simply User_Name when they want to tag a user in a form.

Here is a link to the form if it may help: https://wikimedi.ca/wiki/Formulaire:T%C3%A2che

No, you can just have the template add "User:" to the beginning of each value, using #arraymap - that is what is recommended for such cases.

In that case this parameter can probably be removed.

Setting to "Invalid", given that there's no longer a "namespace" parameter - this should have been done a while ago.