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

Service retirement values from dialog #16799

Merged
merged 4 commits into from
Sep 6, 2018

Conversation

gmcculloug
Copy link
Member

@gmcculloug gmcculloug commented Jan 10, 2018

Building on the changes from PR #16338 (Name service during provisioning from dialog input) this PR adds the ability to set service retirement values from a dialog during service ordering.

The logic sets the retires_on value based on the dialog field name used:

  1. service_retires_on - Date/DateTime value
  2. service_retires_in_days - Duration value (Integer) from current time.
  3. service_retires_in_hours - Duration value (Integer) from current time.

The retirement_warn value for a service is set only if a retires_on value has been specified. It can be set using one of the following dialog field names:

  1. service_retirement_warn_on - Date/DataTime value
  2. service_retirement_warn_in_days - Duration value (Integer) from current time.
  3. service_retirement_warn_in_hours - Duration value (Integer) from current time.
  4. service_retirement_warn_offset_days - Duration value (Integer) from retries_on value
  5. service_retirement_warn_offset_hours - Duration value (Integer) from retries_on value

Links

Steps for Testing/QA

Create a service dialog that specifics one of the fields that sets the retires_on value for a service. Optionally, set a dialog field to specify the retirement_warn value. After ordering the Catalog Item the Service that is created should have the expected retirement properties.

@gmcculloug
Copy link
Member Author

Tests in progress as well as code changes to protect against parsing invalid values.

@miq-bot
Copy link
Member

miq-bot commented Jan 31, 2018

This pull request is not mergeable. Please rebase and repush.

@gmcculloug gmcculloug force-pushed the service_dialog_retirement branch 2 times, most recently from e9b5aa7 to 4be0f14 Compare July 26, 2018 12:04
@gmcculloug gmcculloug force-pushed the service_dialog_retirement branch 2 times, most recently from b81d047 to bf9aead Compare July 30, 2018 17:37
@gmcculloug
Copy link
Member Author

@mkanoor @tinaafitz @eclarizio Still WIP as I need to a several more retirement tests, but I have changed the structure of the code and would appreciate comments/suggestions.

@JPrause
Copy link
Member

JPrause commented Aug 7, 2018

@miq-bot add_label blocker

@miq-bot miq-bot added the blocker label Aug 7, 2018
@JPrause
Copy link
Member

JPrause commented Aug 7, 2018

@gmcculloug if this can be backported to fine and gaprindashvili can you add: fine/yes and gaprindashvili/yes

@JPrause
Copy link
Member

JPrause commented Aug 20, 2018

@gmcculloug is this still a WIP. We have a build today, and wondering if it's ready, so it can be backported.

@gmcculloug
Copy link
Member Author

Yes, still wip so not ready for the build.

Copy link
Member

@eclarizio eclarizio left a comment

Choose a reason for hiding this comment

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

Overall I think this looks like a good step but I'm extremely concerned about how all of the various attributes are set via the meta-programming. I think we could break some of the more complicated attribute setting logic into another class so that it's easier to test, and also easier to see the explicit call instead of just a send.

Ultimately your #parse_options method I think would change to something like:

@attributes[:name] = @options["dialog_service_name"] if @options["dialog_service_name"]
@attributes[:description] = @options["dialog_service_description"] if @options["dialog_service_description"]
retirement_options = SomeRetirementOptionParser.do_the_retirement_parsing(@options)
@attributes.merge(retirement_options)

end

def parse_value(field_name, dialog_field_name, dialog_field_value)
send(field_name, dialog_field_value) if @options.key?(dialog_field_name)
Copy link
Member

Choose a reason for hiding this comment

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

Do we need this if? We're already qualifying the same thing on line 26, and I don't see anywhere else this method is used.

Copy link
Member

Choose a reason for hiding this comment

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

Also I'm concerned about this method since it's a pretty huge feat of meta-programming (hats off to you for accomplishing that one) and it's going to be extremely difficult to unravel later down the line if something needs changing here. Not sure how to solve it quite yet, but maybe some of my other suggestions will make this easier to digest.

end

def retires_on(value)
self.retire_on_date = time_parse(value)
Copy link
Member

Choose a reason for hiding this comment

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

At first I was like "wait a second, why aren't we just doing @attributes[:retire_on_date] = time_parse(value) but then I realized you overrode retire_on_date=. I feel like this whole "retirement" part of this code could be broken out into a whole separate class that purely deals with the parsing of the time. The warning part could even be it's own separate class too, I think.

@@ -1,6 +1,9 @@
describe ServiceTemplate do
include_examples "OwnershipMixin"

# let(:service_user) { instance_double("user") }
Copy link
Member

Choose a reason for hiding this comment

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

Probably don't need this line, haha 😄

Though, I would prefer to use the instance double if we can, but I'm guessing since it's commented out it didn't work for some reason.

end
end

# warn_on warn_in_days warn_in_hours warn_offset_days warn_offset_hours
Copy link
Member

Choose a reason for hiding this comment

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

Looks like this was a reminder to make these specs but they appear to be made above, so I think we can safely remove this.

Copy link
Contributor

@d-m-u d-m-u left a comment

Choose a reason for hiding this comment

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

Looks great except for the screenshotted weirdness.

Copy link
Member

@tinaafitz tinaafitz left a comment

Choose a reason for hiding this comment

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

@gmcculloug Looks good. :-)

Changed to call create!
Refactor create_service method to use create! with a block
@gmcculloug
Copy link
Member Author

@d-m-u Updated with new commit to protect against times in the past.

@mkanoor Please review.

require_nested :Retirement

def initialize(options, user)
@attributes = {}
Copy link
Contributor

Choose a reason for hiding this comment

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

@gmcculloug Is the @attributes needed since we are parsing and just returning a hash back after the parse?


def parse
Service::DialogProperties::Retirement.parse(@options, @user).tap do |attributes|
@attributes[:name] = @options['dialog_service_name'] if @options['dialog_service_name'].present?
Copy link
Contributor

Choose a reason for hiding this comment

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

@gmcculloug
The local attributes is not being used, should @attributes be attributes here.

Copy link
Member Author

Choose a reason for hiding this comment

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

Definitely, it is fixed now.

@miq-bot
Copy link
Member

miq-bot commented Sep 5, 2018

Checked commits gmcculloug/manageiq@9ed98e9~...fd8709d with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
7 files checked, 1 offense detected

app/models/service/dialog_properties/retirement.rb

@mkanoor mkanoor merged commit def0da5 into ManageIQ:master Sep 6, 2018
@mkanoor mkanoor added this to the Sprint 94 Ending Sept 10, 2018 milestone Sep 6, 2018
simaishi pushed a commit that referenced this pull request Sep 7, 2018
@simaishi
Copy link
Contributor

simaishi commented Sep 7, 2018

Fine backport details:

$ git log -1
commit ebe8cebff879016c920e4a6acab1cf8c19509a3d
Author: Madhu Kanoor <mkanoor@redhat.com>
Date:   Thu Sep 6 15:54:59 2018 -0400

    Merge pull request #16799 from gmcculloug/service_dialog_retirement
    
    Service retirement values from dialog
    (cherry picked from commit def0da55c254bd7386b1e1bd9c98f618e7ea7277)
    
    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1626475

simaishi pushed a commit that referenced this pull request Sep 13, 2018
@simaishi
Copy link
Contributor

Gaprindashvili backport details:

$ git log -1
commit 253ce78dfd0e53839189829c4688d526902582a8
Author: Madhu Kanoor <mkanoor@redhat.com>
Date:   Thu Sep 6 15:54:59 2018 -0400

    Merge pull request #16799 from gmcculloug/service_dialog_retirement
    
    Service retirement values from dialog
    (cherry picked from commit def0da55c254bd7386b1e1bd9c98f618e7ea7277)
    
    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1626474

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

Successfully merging this pull request may close these issues.

8 participants