Backend list filtering syntax

[designermonkey]

I'm looking at how Symphony uses filters in backend views as part of some research for the dreaded Relationships issue after a conversation with @brendo, and I have come across a little inconsistency...

When using the linked section counts in the backend to go to the linked section, the link filters the section like so

?filter=status:9

Then when creating an entry, the pre-population of a field uses the following syntax

?prepopulate[86]=9

There's a discrepancy there, especially as @nickdunn's Publish Filtering uses the following to filter

?filter[status]=9

Both filters do their work correctly, and also pre-populate correctly, but there are two methods.

Also, just for reference, what other params are available to the backend, and what tricks do they do? Can you filter with multiple values to pre-populate multiple values in a new entry?

[brendo]

You can use either. handle:value was before Nick beefed up the flexibility.
Both pre population and filtering accept multiple values

[nickdunn]

Handle:value will eventually be deprecated, I noticed the discrepancy
between filter and prepopulate, so 2.3 unified to allow the array syntax on
both. The SBL field (or the way Sym builds these column count links) should
be updated to use the newer array syntax.

Eventually Publish Filtering will allow multiple filters in the one view.

On 25 Aug 2012, at 11:40, Brendan Abbott notifications@github.com wrote:

You can use either. handle:value was before Nick beefed up the flexibility.
Both pre population and filtering accept multiple values

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/1421#issuecomment-8026172.

[designermonkey]

Thanks for the info guys. Should I close this issue, or leave it open to remind us to deprecate the old syntax? When are we thinking of deprecation? 2.4?

[nickdunn]

2.4 works for me. Deprecating anything in maintenance releases is nasty.
Plus gives me time to rework PF with more awesome.

On 26 Aug 2012, at 11:25, John Porter notifications@github.com wrote:

Thanks for the info guys. Should I close this issue, or leave it open to
remind us to deprecate the old syntax? When are we thinking of deprecation?
2.4?

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/1421#issuecomment-8035535.

[6ui11em]

I think could be useful to include prepopulate query string when edit an entry. Now when you make a filter by publish filtering or by clicking on a select box link and click on an entry to edit it the prepopulate query string is lost, after update the entry when you click the "View all entries" link go to the entire section list loosing the filter. I think could be useful to keep the filter to go back to the filtered list when click "View all entries".

I implemented this in some installation where I need it. It's just a few lines in /symphony/content/content.publish.php

[brendo]

Submit a pull request ?

[6ui11em]

Ok, I will fork the repo and make a pull request.

---

Brendan Abbott mailto:notifications@github.com
27 de agosto de 2012 16:38

Submit a pull request ?

—
Reply to this email directly or view it on GitHub
#1421 (comment).

[designermonkey]

That's actually part of the issue that was raised at 2011 Symposium regarding Symphony's relationships handling. If you can get that fixed then awesome, as it helps me out in scoping proposed changes to how Symphony handles relationships.

[brendo]

So, the question now is, should we have both View filtered entries and View all entries links? At the moment @6ui11em's pull request will make View all entries show the filtered entries view, not all the entries of the current section.

Is this potentially misleading text? Should we have Create another?, View filtered entries, View all entries in the notification, or is it too much clutter? Is it clear that View all entries will take you to a filtered view?

[6ui11em]

For me just 2 links is enough, but may be we could change the message of "View all entries" to "Back to list" or something like this to avoid confusions?

[nilshoerrmann]

If the backend displayed View filtered entries my first question was: what is it filtered by?
We don't display that information in the backend at the moment (it's in the URL but who is aware of this?).

[designermonkey]

This raises the question of: Why is Publish Filtering not in the core?

We have all the filtering logic in the core with regards to url params etc, but no UI to do it with without installing an extension.

It's a major feature request for all clients I\ve worked with, so should be a core feature to tie the whole thing together.

In answer to the question above, it should definitely be only the two links. To get to a filtered view, the user would either use the raletions links, or Publish Filtering, so if they create a new entry, I'm sure they would expect to see the return index as the same as they left it. Makes sense to me.

It fixes the workflow to some degree too, as was discussed at Symposium 2011, which is broken without this addition.

@6uillem, does all this filtering work with new entries too? Returning to the filtered list I mean?

[nilshoerrmann]

There is one problem we should take into account: SBL is filtering content to display related entries (clicking on the links in an index table, e. g. 12 →). While this might be obvious to us it's certainly not for normal authors. I, in their place, would be quite irritated if the system UI said something about filtered entries ("But I haven't filtered anything, I was just looking at the comments!").

[designermonkey]

Agreed.

I think we can all agree that the current state within the pull request is how it should be.

Problem solved! Nice hustle team! ;o)

[nickdunn]

Breadcrumbs.

On 30 Aug 2012, at 05:32, "Nils Hörrmann" notifications@github.com wrote:

There is one problem we should take into account: SBL is filtering content
to display related entries (clicking on the links in an index table, e. g. 12
→). While this might be obvious to us it's certainly not for normal
authors. I, in their place, would be quite irritated if the system UI said
something about filtered entries ("But I haven't filtered anything, I was
just looking at the comments!").

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/1421#issuecomment-8157764.

[designermonkey]

Just to clarify...

When we're talking about deprecating the : type of filter syntax, is that when we change it to [] type syntax? If so, I'll hold off submitting my pull request.

[nickdunn]

Yep. filter[field]=value is the new syntax, filter=field:value to be deprecated. But not to be deprecated in a 2.3.* maintenance release; 2.4.

The new syntax should already be functional in 2.3, it was updated to be aligned with prepopulate.

[designermonkey]

Sorry guys. I'm reopening this issue as what I expected to be implemented is not working.

@6ui11em's pull request was discussed as adding the filter back in on the View All Entries link, and also on the Breadcrumb link, but sadly, this isn't the case on the integration branch. The only link working is the prepopulate when clickingCreate Another?