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

Add resource instance variables and audit log sample #2478

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

goosys
Copy link
Contributor

@goosys goosys commented Dec 26, 2023

I have made changes so that instance variables are stored in both the index and create actions, in order to capture controller operation logs and perform other post-processing tasks.
Please review.

@goosys goosys force-pushed the resource-instance-variables branch 2 times, most recently from e77fb39 to 7d6f2c4 Compare December 26, 2023 06:55
@pablobm
Copy link
Collaborator

pablobm commented Oct 29, 2024

I'm ok with this, but I think it should be consistent and always be @resource (and @resources for the plural case).

Thoughts, @nickcharlton?

@nickcharlton
Copy link
Member

Ah yeah, I see. Yeah, consistency is important here.

@goosys goosys force-pushed the resource-instance-variables branch from 7d6f2c4 to f54ada5 Compare February 20, 2025 07:58
@goosys
Copy link
Contributor Author

goosys commented Feb 20, 2025

rebased

def audit_log
if (resource = @requested_resource || @new_resource)
Rails.logger.info(
sprintf(
Copy link
Member

Choose a reason for hiding this comment

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

Hah! It's so rare to see the use of a sprintf, fun!

@@ -26,7 +27,7 @@ def show
end

def new
resource = new_resource
@new_resource = resource = new_resource
Copy link
Member

Choose a reason for hiding this comment

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

@pablobm, where you thinking that this should be @resource and not @new_resource? I'm not sure if we made any changes here after that comment

Copy link
Collaborator

Choose a reason for hiding this comment

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

That's right. Unless there's a reason for it, I think this should be @resource for consistency.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Actually... now I'm torn. I forgot that we have @requested_resource, so having @resource might be confusing 🤔

Copy link
Contributor Author

@goosys goosys Mar 22, 2025

Choose a reason for hiding this comment

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

https://github.com/goosys/administrate/blob/20cf3a7ab273e17312033ca1d3ed2e1c1503623f/app/controllers/concerns/administrate/resource_manager.rb#L24

I was reorganizing ApplicationController for a separate task, and I think @built_resource would be a good choice.

It clearly indicates that the resource is not yet saved, making it more explicit than simply using @resource.

Copy link
Collaborator

Choose a reason for hiding this comment

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

This makes me uneasy... 🤔 Increasing the number of instance variables increases complexity. In your audit_log for example, having to do if (resource = @requested_resource || @new_resource) is a smell. I would prefer to do if @resource. The action can be obtained from action if further filtering is required.

As mentioned, the presence of @requested_resource complicates things a bit... I'm looking at it now and I think that's the problem: a noun-method that should be a verb-method. I think instead we should do this in update, edit, destroy:

    def update
      @resource = find_resource(resource_params)
      if @resource
        redirect_to(
          after_resource_updated_path(@resource),
          notice: translate_with_resource("update.success"),
          status: :see_other
        )
      else
        render :edit, locals: {
          page: Administrate::Page::Form.new(dashboard, @resource)
        }, status: :unprocessable_entity
      end
    end

Which now relies on verb-method (also requires renaming the pre-existing find_resource):

    def find_resource
      find_resource_in_scope(params[:id]).tap do |resource|
        authorize_resource(resource)
      end
    end

    def find_resource_in_scope(param)
      scoped_resource.find(param)
    end

This is now consistent with index,new, and create, which retrieve the resource with a helper method and put it in an instance variable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I liked the approach with @requested_resource, so I hadn't considered changing it. But now, as you mentioned, I think using @resource is better.

@@ -40,7 +41,7 @@ def edit
end

def create
resource = new_resource(resource_params)
@new_resource = resource = new_resource(resource_params)
Copy link
Collaborator

Choose a reason for hiding this comment

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

And same thing here:

Suggested change
@new_resource = resource = new_resource(resource_params)
@resource = resource = new_resource(resource_params)

@@ -9,6 +9,7 @@ def index
resources = apply_collection_includes(resources)
resources = order.apply(resources)
resources = paginate_resources(resources)
@resources = resources
page = Administrate::Page::Collection.new(dashboard, order: order)
Copy link
Contributor Author

@goosys goosys Mar 27, 2025

Choose a reason for hiding this comment

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

@nickcharlton @pablobm
If it's for the audit log, I feel like having @page would be nice too. Thoughts?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Given how prevalent it is (it appears in all actions that render a page), I think it may make sense, yes 👍 Go for it.

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.

3 participants