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

Promote supports feature to ApplicationRecord #23140

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

Conversation

kbrock
Copy link
Member

@kbrock kbrock commented Aug 10, 2024

Most models include SupportsFeatureMixin. This moves up to ApplicationRecord +1/-73

@kbrock kbrock added the cleanup label Aug 10, 2024
@Fryguy Fryguy self-assigned this Aug 14, 2024
@Fryguy
Copy link
Member

Fryguy commented Aug 14, 2024

@agrare Please also review.

Adding supports feature to a few more core models.
It makes sense to have this as a base class for all
@kbrock
Copy link
Member Author

kbrock commented Aug 22, 2024

update:

  • rebased
  • extracted tools/feature_supports_matrix change (already merged)
  • extracted ReadOnlyModels change (closed that PR)

@kbrock kbrock changed the title Promote supports feature to ApplicationSupport Promote supports feature to ApplicationRecord Aug 22, 2024
@miq-bot
Copy link
Member

miq-bot commented Aug 22, 2024

Checked commit kbrock@bfbecf9 with ruby 3.1.5, rubocop 1.56.3, haml-lint 0.51.0, and yamllint
64 files checked, 0 offenses detected
Everything looks fine. 🏆

@@ -12,6 +12,7 @@ class ApplicationRecord < ActiveRecord::Base
include ArHrefSlug
include ToModelHash
include ArVisibleAttribute
include SupportsFeatureMixin
Copy link
Member Author

Choose a reason for hiding this comment

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

this is the 1 addition.

Moves this include to ApplicationRecord

@Fryguy
Copy link
Member

Fryguy commented Sep 19, 2024

Most models include SupportsFeatureMixin. This moves up to ApplicationRecord +1/-73

I understand the intent to avoid duplication here, but "most models" isn't really accurate. There are 457 models roughly, and only 73 have this, which means only 16% of models are like this.

One upside to having it in specific models is we can know what models are the things that are "CI"s (i.e. things that we externally manage). That gets me wondering if we should have a CIMixin where we take a lot of these common mixins across CIs, then include that. But overall, I'm not sure that would make any benefit.

I'm not against this PR, but I'm not sure - would like a second opinion from @agrare and/or @jrafanie

@jrafanie
Copy link
Member

One upside to having it in specific models is we can know what models are the things that are "CI"s (i.e. things that we externally manage). That gets me wondering if we should have a CIMixin where we take a lot of these common mixins across CIs, then include that. But overall, I'm not sure that would make any benefit.

haha, if you can name what this commonality is, we could probably create it. Ideally, all of these things should be reportable, support features, taggable, etc. We can override in classes that can't do one or more of these things if desired. Not sure how much we want to pull into the common place.

@kbrock
Copy link
Member Author

kbrock commented Sep 19, 2024

I think having a plugin that says "I'm a taggable, rbac applyable, data model that is in each provider" may have merit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants