PnP search Refiner WebPart(v4.1) – File Types should group and show user friendly names

[ShariqSiddiquie]

Is your feature request related to a problem? Please describe.
Search refiner template group the similar file types and show user friendly names.
We have this feature in SharePoint 2013

Describe the solution you'd like
All similar file types should club in one group and the group name should be user friendly.
Ex :- “Word” group (.doc, .docx)

Describe alternatives you've considered
This feature should be in PnP Search refiner similar as SharePoint 2013. Actual file type names are not user friendly.

Additional context
Please see the attached document with screenshots

PnPSearchRefiner(v.1) FileType group and user friendly names.docx

[ShariqSiddiquie]

This is a very good feature in SharePoint 2013. It would be great if we get this feature in PnP Refiners.
When we can expect to get this feature in PnP Search Refiners?

[wobba]

When someone from the community builds it :)

[edarroudi]

If i implement this i would like to build a more generic approach (not only for fileType). Any idea / suggestion how the configuration should look like?

[wobba]

You would need one or more property matching expressions which is used to group over to a UX label. Pseudo logic below, and question is how advanced you want to get with AND/OR's.

Label = Document
   FileType contains doc
   OR FileType contains pdf
   AND SPContentType equals CoolDoc
Label = Spreadsheet
   FileType contains xls

where the expressions must support being translated into FQL when you click on them.

[wobba]

@edarroudi You can use hooks if you want, but mixing and matching patterns may make code more cluttered. So I'm a bit ambivalent.

[FranckyC]

Same here, I find hooks hard to read in my opinion. If you prefer this option, why not but make it easy to read and follow.

[edarroudi]

Hi guys,
i implemented a bit of the layout for the grouped refiners and wanted to ask if i go into the right direction here.
I believe that most users only need a simple grouping with a list of values that belong to the "group label".
I have an advanced option in mind where the user can just write some FQL themselves - with no checks on our end.
Do you see any issues here? I don't want to implement a FQL editor or funny stuff like that. Mayvbe we have to think about some security issues here.

Another question would be the sorting behaviour:

1. Should groups always stay at the top of the refinement control
2. Should it be handled by the "Sort values by" and "Sort direction" properties?
3. Should i add Sort options for the group, like for "Sort Values by" an option like: "By group, name"
4. Should users be allowed to sort the group labels (right now it's iimplemented like this)

What do you think about "Double value" checking:
Lets say we have a label called Documents with values "pdf,doc,xls" and a label called Word with values "docx, doc".
As far as i understand this would be ok from the technical point of view, i just don't know if we should allow it. If we allow "advanced mode" this will probably be complex to check.

[wobba]

Can you share a branch url?

[edarroudi]

Hey @wobba that branch is not in a status i would dare to share :) Just didn't want to waste my time to fully develop the features not knowing if you guys will accept those features & how i implement them. Normally i discuss a "user story" before i implement it. I will create a new feature branch once i know what you guys think about my questions from above.

[wobba]

@edarroudi I think the UX looks ok. What would happen if you click on a grouped value? What would the expression be, and it has to work for both the Graph and the SP provider.

[edarroudi]

@wobba thanks for your reply. I tested both in SharePoint & Graph DataSource the following requests and they worked.
SP pass following RefinementFilters:
Option a)

{
    "results": [
        "FileType:Or(\"ǂǂ6a7067\",\"ǂǂ706466\")"
    ]
}

Option b)

{
    "results": [
        "FileType:Or(zip,pdf)"
    ]
} 

In Graph
Option a)

"aggregationFilters": [
        "fileType:or(\"ǂǂ706466\",\"ǂǂ646f6378\")"
]

Option b)

"aggregationFilters": [
                "fileType:or(pdf,zip)"
            ]

So looking at the option "b" it seems that we can pass direct fql as advanced option. I probably would use option "a" in simple mode and option b in advanced mode for performance issues?

Clicking on the group value will have the same behaviour as clicking any other filter value. I don't plan on implementing any special treatment here. But of course i'll try out some scenarious like when the user clicks on group "word" (doc, docx) and there is already a selected "doc" filter in the checkbox...

[wobba]

I think both option a and b perform exactly the same. Using encoded tokens might be preferable when they are available on the response, but I have no strong feelings how the filter FQL is crafted.

[edarroudi]

I created a draft version - perhaps you can have a look if you have some spare time.

[edarroudi]

I created a draft version - perhaps you can have a look if you have some spare time.

Hey @wobba , did you have some time to look at the draft? I would like to finish it for the next version... #1845 . Thank you!

[edarroudi]

hey @wobba, as my PR was closed without a comment I was wondering if you guys don't want this feature or I should merge it with the new version for a review - It's ok if there is no need for it but I would appreciate some feedback on this matter.

[wobba]

@edarroudi closed by accident. Sorry about that.

[edarroudi]

@wobba yeah thanks but it is still closed #1845 . You opened only the other one.

[wobba]

Re-opened. And will have to review it.