Create report types

[lpichler]

alternative of #209:

Taken from @hstastna's description:
What:
We need to store the type of the Rate which is related to type of Report: Chargeback for VMs/Images/Projects.

Why:
We need it for adding new drop down to editing screen for Rate to be able to choose the type of the rate and then to display only appropriate columns of the rate, based on the chosen type of the rate (VMs, Images, Projects).

I added selected option 2 #209 (comment) option after our discussion.

The only difference is that I created more general table ReportType - even If I don't have other use case at this moment.

ReportType is new one.

cc @gtanzillo @carbonin @hstastna

Links

https://bugzilla.redhat.com/show_bug.cgi?id=1581817

[miq-bot]

Checked commit lpichler@debbcd3 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
1 file checked, 1 offense detected

db/migrate/20181107164348_create_report_type.rb

• ❗ - Line 9, Col 30 - Style/SymbolArray - Use %i or %I for an array of symbols.

[carbonin]

I'm not sure report_types is the best name here. Maybe reportable_fields?

This table will store one row per entry in https://github.com/lpichler/manageiq/blob/ce3bb5dc39eb168a70a9f6be73ed496cb5dc6c22/app/models/chargeback_vm.rb#L2 right?

[lpichler]

first usage, is for ChargeableField. One row of ChargeableField could have 2 chargeback report types. For example, v_derived_cpu_total_cores_used belongs to ChargebackContainerImage, ChargebackContainerProject chargeback report types.

So firstly I was modeling:

ChargeableField has_many ChargebackReportType and then
I realized that probably it could be useful to don't limit ourselves and go with general way:

ChargeableField has_many ReportType

due this facts, I think that name reportable_fields doesn't explain the idea of intended report types. But as my native language is not english - I could be wrong :)

what do you think now?

thanks!

[carbonin]

I'm still not sure what the resource is pointing to in that case? If its something inheriting from Chargeback then there won't be a database row, but if it's ChargeableField then why make it polymorphic?

[carbonin]

Also, I'm curious about why something like ChargebackVm.attribute_names wouldn't satisfy this requirement ("I need all the fields that apply to a particular type of chargeback report").

Is that something we considered over editing the schema?

[lpichler]

closing for, we have other solution