Edit VM Form - react

[himdel]

Converting Edit VM Form to React so that we can add authentications..
And also fix #6617.

API endpoint for editing: ManageIQ/manageiq#14623

[himdel]

The current logic for available parents:

  def parent_choices(ids)
    @parent_choices = {}
    @parent_choices[Digest::MD5.hexdigest(ids.inspect)] ||= begin
      ems_ids = VmOrTemplate.where(:id => ids).distinct.pluck(:ems_id).compact
      parent_item_scope = Rbac.filtered(VmOrTemplate.where(:ems_id => ems_ids).where.not(:id => ids).order(:name))

      parent_item_scope.pluck(:name, :location, :id).each_with_object({}) do |vm, memo|
        memo[vm[0] + " -- #{vm[1]}"] = vm[2]
      end
    end
  end

  def parent_choices_with_no_parent_choice
    {'"no parent"' => -1}.merge(parent_choices(@record.id))
  end

= select_tag("chosen_parent",
                    options_for_select(parent_choices_with_no_parent_choice, @edit[:new][:parent]),

[himdel]

The logic for children:

Child VMs...

    vms = @record.children # Get the child VMs
    @edit[:new][:kids] = {}
    vms.each { |vm| @edit[:new][:kids][vm.name + " -- #{vm.location}"] = vm.id } # Build a hash for the kids list box

Available VMs...

vms = @record.children
...
@edit[:choices] = parent_choices([@record.id] + vms.pluck(:id))

[NickLaMuro]

@himdel I assume that these ruby code examples from your two comments are what are available in manageiq-ui-classic, and some form of this functionality needs to exist in the API (if it doesn't already).

Correct?

[himdel]

What parent_choices does is return all VMs for the given providers, except for the VMs provided :).

So, available parents currently doesn't care if the VM is also in children,
and for available children, we only care about skipping the VMs already in .children

So, to keep the existing logic, we only need:

• edited VM's provider id (available as .ems_id in /api/vms/1)
• edited VM's children ids
• all VMs under that provider (/api/vms/?filter[]=ems_id=55&expand=resources)

[himdel]

@NickLaMuro exactly the point .. I think we already have everything, iff I'm reading that right and if we want to keep the logic as is.

(Can you double check my logic please? :))

[NickLaMuro]

(Can you double check my logic please? :))

Yup, no problem. Just saw this come in and wanted to make sure I understood what was being referenced here, since @skateman pinged me about this earlier today.

Will be looking into this a bit more this evening, and will report back here then. 👍

[himdel]

Perfect, thanks! :)

[himdel]

Assuming my logic works, there are only 2 problems:

• no way to get a list of VMs children via the API (tried /api/vms/1?expand=children or attributes=children)
• no way to get a VMs parent via the API (.parent_id is not there)

(And one note - archived/orphaned VMs should have that part disabled, no ems_id.)

[NickLaMuro]

Okay, sounds feasible if it isn't already. I admit it takes me a while to find what is and isn't already in the API, so it might take me a "hot minute" to determine what is available.

[himdel]

Yeah, me too, especially for custom-implemented things..

Such as this case :) ... /api/vms/1?attributes=child_resources,parent_resource does give me both children and parent (when present).

[himdel]

@NickLaMuro but I think the current code may be wrong...

manageiq/app/models/vm_or_template.rb
virtual_has_many   :child_resources,        :class_name => "VmOrTemplate"
virtual_has_one   :parent_resource,      :class_name => "VmOrTemplate"


  def child_resources
    children
  end

  def parent_resource
    parent
  end

There's no RBAC.filtered involved anywhere. Unless the API somehow understands that that particular virtual attribute is a collection and needs rbac filtering.

[NickLaMuro]

@himdel it should, but I would have to check... pretty sure all attributes in the API are Rbac.filtered, but want to confirm.

Let me look into it.

[NickLaMuro]

@himdel Okay...

As a quick primer, the attributes from your query above are accessible in the controller thanks to these two methods:

https://github.com/ManageIQ/manageiq-api/blob/cd849c1/lib/api/request_adapter.rb#L36-L38
https://github.com/ManageIQ/manageiq-api/blob/cd849c1/app/controllers/api/base_controller/parameters.rb#L50-L58

And the part that filters it is from the base_controller/renderer.rb module, which the important bits are the following two sections:

https://github.com/ManageIQ/manageiq-api/blob/cd849c1/app/controllers/api/base_controller/renderer.rb#L79
https://github.com/ManageIQ/manageiq-api/blob/cd849c1/app/controllers/api/base_controller/renderer.rb#L201-L219

So I think we should be good, assuming the child_resources/parent_resource are considered virtual_attributes, but I am pretty sure the RelationshipMixin in manageiq would have it treated as virtual_attributes.

(to be fair, I think the code that determines if it is "virtual" basically checks if it is a relation as well, so that should be any non-column/non-vanilla-ruby-method method on an ActiveRecord object... but I will check that as well)

Edit: Oh, nevermind, these are straight up virtual_* based relations:

https://github.com/ManageIQ/manageiq/blob/a59c2aa/app/models/vm_or_template.rb#L164
https://github.com/ManageIQ/manageiq/blob/a59c2aa/app/models/vm_or_template.rb#L170

So these will definitely be picked up by this:

https://github.com/ManageIQ/manageiq-api/blob/cd849c1/app/controllers/api/base_controller/renderer.rb#L350-L356