Field name instead of dimension name in current selections?

[#1]

Why does the current selection show the field name when you select a named dimension? Is this a bug?

Cheers

Karl

[datanibbler]

Hi Karl,

I don't know what exactly you mean - but I think the current_selections_box is somewhat inflexible as to what names you want to display to the user.

To be more flexible, you would have to design your own version of that using the Getcurrentselections() function.

HTH

[#3]

Hi HTH,

In my opinion the current selection should show the dimension name. For the end-user it's really confusing if they select Year as a dimension in a chart and it shows up as date_key.Calendar.Year. You create dimension for the end-user so they don't see the "ugly" field names.

[awhitfield]

Hi Karl, check the properties in the Current Selection box, have you got 'Values' ticked? The fields column is always shown, but you can enable / disable Values (Field Name)

Andy

[#5]

I think I didn't explain my self properly. Let's try it again.

This is how it shows up with no selections. Great!

But when I select 2015 in the dimension Year it shows the field name instead. This is the same for all fields, not just the derived calendar fields. Ugly!

And this is how it shows up when the current selection tool is closed. Ugly!

[#6]

Qlik Sense Server 1.1.0

[Michael_Tarallo · Accepted solution]

Hi Karl - thanks for your question. You have two things going on here.

1) From the screenshot - (seeing date_key.calendar.year) - I assume you are using a calendar field generated by the DECLARE and DERIVE statements and these are under the Date and time field section in the fields list? If that is the case - it is using the long name that is generated from this process. This is known and is being addressed.

2) The Global Selections panel will display the alias name, such as : Year(mydate) as Year - that is used in the LOAD SCRIPT only at the moment. It does not respect the Name field that is given to the Dimension that is created in the Master Items list. As stated this is known and is being addressed.

At the moment, you could shortened the name of your date fields and calendar fields to attempt to clean them up a bit, but I do realize that is not the perfect solution.

Please let me know if you have any other questions.

Please mark the appropriate replies as CORRECT / HELPFUL so our team and other members know that your question(s) has been answered to your satisfaction.

Regards,

Mike Tarallo

Qlik

[#8]

Hi Mike,

Great to hear that the issues are addressed and worked on. I also noted that the autorsort doesn't work for the derived fields. Is that also known?

Since the derived calendar doesn't work in set analysis yet, I think I'll stick to creating my own calendar.

Do you have a timeframe for all these fixes?

And will there be some alternative date state implemented?

Thanks again for a quick response

Karl

[Michael_Tarallo]

Hi Karl - yes - auto-sorting is also known, but you can work-around that with sort by expression, I believe.

I agree with your own calendar for now - BTW - what you are actually seeing in that DERIVE / DECLARE example of that calendar is really the introduction / beginnings to auto-generating dimensions for the Master Items via the script instead of having to add each one manually in the master items. A welcomed addition to app automation. This will eventually include support for Drill-down etc.

I don't have a timeframe as of yet, but stay tuned, I am not sure on the alternate states, but as soon as I know it is / will be available you will definitely hear about it.

Thanks again and stay in touch with us.

Mike T

Qlik

[#10]

One more thing I noticed that I forgot to mention. When I derived the calendar from a field that has a hideprefix the calendar fields doesn't show up. Is that also a bug?