Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Search scopes #276

Closed
wants to merge 95 commits into from
Closed

Search scopes #276

wants to merge 95 commits into from

Conversation

nando
Copy link
Contributor

@nando nando commented Nov 27, 2015

DISCLAIMER: the original message of this PR written two months ago has been updated to represent better its current state (however the original one has been kept at the end).

Problem:
If the resource managed by the dashboard has scopes defined there's no way to limit the scope of the search with them.

Solution:
Declare a new constant in the dashboard (COLLECTION_SCOPES) to define the valid scopes that could be used in the query while searching in the index page. The following is the current definition of the COLLECTION_SCOPES constant in the template used to generate new dashboards:

  # COLLECTION_SCOPES
  # an array or hash that define the valid scopes that could be used while
  # searching as part of the query string.
  COLLECTION_SCOPES = []  # Comment to use any scope, but read this text below.
  # If the above COLLECTION_SCOPES definition doesn't exist then any "scope"
  # defined could be used searching *scope:<name_of_the_scope>*. Though this
  # could be a nice feature in applications that has the dashboard access
  # properly secured **this approach is not recommended**. Administrate has
  # no way to know the scopes defined in the model and will send to the model
  # anything not included in its blacklist.
  #
  # When defined buttons will appear in the index header in order to filter the
  # resources displayed. If it's an array it will be treated internally as if
  # it were a hash with a single key called *scopes* pointing to our array. The
  # hash's keys and the scope definitions will be used to show a localized
  # caption for each button using *administrate.scopes.<model_class>* as I18n's
  # scope. If no translation the scope in that model, Administrate'll retry the
  # translation with the scope *administrate.scopes*. That will let us share
  # the same translation between different models (and be DRY!).
  #
  # Definition example with an Array:
  #
  #   COLLECTION_SCOPES = [
  #     :opened,
  #     :closed
  #   ]
  #
  # Definition example with a Hash:
  #
  #   COLLECTION_SCOPES = {
  #     status: [:opened, :closed],
  #     headquarters: [:madrid, :oviedo, :mexicodf]
  #   }
  #
  # Scopes with an argument can also be defined. An explicit value for the
  # argument can be defined adding that value after scope name between
  # parenthesis and without quotes. For example:
  #
  #   COLLECTION_SCOPES = {
  #     headquarter: ["office(madrid)", "office(oviedo)", "office(mexicodf)"]
  #   }
  #
  # Will use the scope *office(city)* using "madrid", "oviedo" and "mexicodf"
  # as arguments.
  #
  # Finally, it's possible to let the user indicate the value of the argument
  # as part of the search query adding ":*" after the scope name. For example:
  #
  #   COLLECTION_SCOPES = {
  #     headquarter: ["office(madrid)", "office(oviedo)", "office:*"]
  #   }
  #
  # Won't show any scope button for "office:*" but will let us indicate any
  # value after "office:" to use it as argument for the *office(city)* scope.
  # If our search query is "office:mexicodf" we'll get the same results than
  # clicking in the third button of the previous example (which query would be
  # "scope:office(mexicodf)").

ORIGINAL MESSAGE
I hope you like the idea (I've modified the original PR to avoid sending the scope to the model if it looks suspicious. We do not have that security problem in our project since our AdministrateController has 'before_filter :require_admin' at the beginning of its definition.


scenario "admin searches using a model scope", :js do
query = "subscribed:"
subscribed_customer = create(:customer, name: "Dan Croak", email_subscriber: true)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line is too long. [86/80]

@nando nando mentioned this pull request Nov 27, 2015
name: "Dan Croak",
email_subscriber: true)
other_customer = create(:customer,
name: "Foo Bar",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Align the parameters of a method call if they span more than one line.

nando added 2 commits December 2, 2015 11:10
Does not send the possible scope to the class if it looks suspicious, that's to say:
  - contains any of the BLACKLISTED_WORDS
  - ends with an exclamation mark
I've also made public the :resolver, :term and :scope to be able to test this behavior (:resolver and :term not needed but can't see the problem of them being public too).
end
end

search = Administrate::Search.new(resource_resolver, 'bang!:')

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping.

if term && (term[-1, 1] == ":")
possible_scope = term[0..-2]
possible_scope if resource_class.respond_to?(possible_scope) &&
!banged?(possible_scope) &&

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use 4 (not 18) spaces for indenting a condition in an if statement spanning multiple lines.


COLLECTION_SCOPES = {
status: [:active, :inactive, "idle", "with_argument:*"],
other: [:last_week, :old, "with_argument(3)",],

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Avoid comma after the last item of an array, unless each item is on its own line.

@pcriv
Copy link

pcriv commented Mar 31, 2016

+1

alfonsojimenez pushed a commit to alfonsojimenez/administrate that referenced this pull request Apr 2, 2016
Conflicts:
	spec/example_app/app/models/customer.rb
	spec/spec_helper.rb
@@ -14,3 +15,38 @@
end

WebMock.disable_net_connect!(allow_localhost: true)

class MockDashboard < Administrate::BaseDashboard
ATTRIBUTE_TYPES = {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Freeze mutable objects assigned to constants.

@ahmgeek
Copy link

ahmgeek commented Apr 26, 2016

will it ever be merged anytime soon ?

@estiens
Copy link

estiens commented Jul 22, 2016

A few months later...

@nando
Copy link
Contributor Author

nando commented Jul 23, 2016

We are using this branch merged with others that let use Administrate w/ Globalize and Pundit with this lines in our Gemfile:

gem 'administrate', git: 'git@github.com:nando/administrate.git', branch: 'fgs_globalize_and_search_scopes'
gem 'administrate-field-image'

We are using Administrate to manage resources in our new website and are very happy and grateful to Thoughtbot and Grayson for this amazing gem (thanks again!!)

Hopefully they merge it one day. It would be a great honor for me, i admire Thoughtbot from its very beginning ;)

@bastianwegge
Copy link

bastianwegge commented Apr 4, 2017

@Graysonwright @tysongach what's up with this PR?

It's clearly something people are requesting as in: #157, #183, #277, #291, #563, #445

I'd be glad to help solve any issues or interferences you see upcoming with this code. 🌮

@pustomytnyk
Copy link
Contributor

@nando I believe you unfortunately are the only one who can rebase this :)

@koppen
Copy link
Contributor

koppen commented Jun 20, 2017

I'd be willing to help getting the PR in shape and already have a branch where this has been merged into a fresh master over at https://github.com/substancelab/administrate/tree/collection_scopes.

It's a huge PR, though, and there are still some issues I need to weed out (layout and a few failing specs) - I guess that is to be expected with a year old feature branch that has lived through v0.2
to 0.7, a redesign and whatnot 😀

That said, I have no idea what the best approach is. Just submit a new PR with what I have? Somehow rebase and clean up the branch (that seems near-impossible)? Cherry-pick the relevant commits on top of master?

Also, I'd very much prefer to not step on @nando's toes here by stealing credit or ruffling feathers, please advice.

@nickcharlton
Copy link
Member

Hi @koppen!

When I pick up old PRs and the original author hasn't replied for a while, I usually take their branch, rebase it against current master (this will ensure their original authorship is retained) and open a new PR. We can close this one once you do that.

As it is quite big, if you think it could be broken down I'd do that and cherry pick a few commits over a collection of different PRs.

As long as you work with @nando's original commits (even if you break them apart a bit), the credit will stay.

@koppen
Copy link
Contributor

koppen commented Jul 22, 2017

So I wasn't able to cherrypick my way to a working branch - at least not in any sensible manner - so I've ended up reimplementing some of @nando's original ideas on a fresh master. Pull request is at #947 .

@nickcharlton
Copy link
Member

I'm closing this as we've got #947 now.

@nando nando deleted the search_scopes branch June 28, 2018 17:54
@nando nando restored the search_scopes branch June 28, 2018 17:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.