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

134929249 two flash messages bug #418

Merged

Conversation

OlenaCh
Copy link
Contributor

@OlenaCh OlenaCh commented Dec 21, 2016

Fixes: https://www.pivotaltracker.com/story/show/134929249

  1. Fixing bug with an error flash message
  2. Fixing bug with appearance of two flash messages which of them is informing that an organization was successfully approved. Currently, organizations can be approved only if they have valid email and only in this case the abovementioned success message will be shown.
  3. Adding relevant RSpec tests and slightly changing existing Cucumber tests.

create_invitation_response_object(InviteUnregisteredUserFromProposedOrg.new(@email,org).run, org)
begin
accept_organization
rescue Exception
Copy link
Member

Choose a reason for hiding this comment

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

Could we rescue a specific error here rather than Exception?

Also, you can remove the begin ... rescue ... end, and just have rescue to spaces to the left. http://seejohncode.com/2012/04/17/short-tip-rescuing-a-method-in-ruby/

def accept_organization
org = @proposed_org.accept_proposal
@result = inform_user org
raise Exception if [Response::NOTIFICATION_SENT,
Copy link
Member

Choose a reason for hiding this comment

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

To raise a domain-specific error, we could do the following:

class NotificationError < StandardError; end

def accept_organisation
  # raise NotificationError if ...
end

@johnnymo87
Copy link
Member

Please replace all references to organization with organisation 🇬🇧 😉

@OlenaCh
Copy link
Contributor Author

OlenaCh commented Dec 22, 2016 via email

@OlenaCh
Copy link
Contributor Author

OlenaCh commented Dec 28, 2016

I've changed code according to the recommendations and Code Climate requirements. Thank you! :)

@johnnymo87
Copy link
Member

+1 nice tests

@OlenaCh
Copy link
Contributor Author

OlenaCh commented Dec 28, 2016 via email

Copy link
Contributor

@Maroo-b Maroo-b left a comment

Choose a reason for hiding this comment

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

@OlenaCh really good PR just a note about code style in Ruby, avoid adding multiple statement in same line with semicolon.

@@ -1 +0,0 @@
rvm use 2.3.1@localsupport --create
Copy link
Contributor

Choose a reason for hiding this comment

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

is there a reason to delete the .rvmrc file ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, I'm sorry, I did not delete it on purpose. Perhaps, it was deleted accidentally and I did not notice, so did not create again. I'll fix it.

redirect_to organisation_path(result.accepted_organisation) and return false
rslt = prepare_data_for_update
redirect_to organisation_path(rslt.accepted_org) and return false if rslt.accepted_org
redirect_to proposed_organisations_path
Copy link
Contributor

Choose a reason for hiding this comment

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

what about using if/else block like

if rslt.accepted_org
  redirect_to organisation_path(rslt.accepted_org)
else
  redirect_to proposed_organisations_path
end

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, that was the first version of the code; but CodeClimate analysis marked it as an issue of ABC complexity (too much if/else statements for update method). Should I return back to the previous version?

Copy link
Contributor

Choose a reason for hiding this comment

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

it's not a blocker for my side when I have two alternatives I pick the one that make my code easier to read.

Copy link
Contributor Author

@OlenaCh OlenaCh Jan 10, 2017

Choose a reason for hiding this comment

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

Yes, of course, I understand. I am sorry, but may I ask about clarification, please? It will add two additional CC issues (6 instead of 5 allowed lines of code in one method & ABC complexity). It is not a problem to change these lines, but one of first comments on my PR was about necessity to address CodeClimate issues (when we discussed it on Slack with @tansaku).

Copy link
Contributor

Choose a reason for hiding this comment

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

@OlenaCh that's strange because I saw only the redirection condition on update method, you can keep the current implementation.
Generally when it comes to CodeClimate warnings, it's always better to address those warnings but sometimes you can ignore it but you need confirmation from reviewers :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, thank you very much :) !


def accept_organisation
org = @proposed_org.accept_proposal; @result = inform_user org
raise NotificationError if success?(@result.status) == false
Copy link
Contributor

Choose a reason for hiding this comment

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

when it comes to predicate method (ends with ? like success?) you don't need to compare with boolean for example we can change the expression to:

raise NotificationError unless success?(@result.status) 

Usually I avoid using exception for managing the flow, it's ok to use it but as alternative I would check the status of inform_user before accepting the organisation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you! I'll fix it! :)

org = becomes!(Organisation)

def accept_proposal(rollback = false)
org = rollback ? becomes!(ProposedOrganisation) : becomes!(Organisation)
Copy link
Contributor

Choose a reason for hiding this comment

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

I understand that there is change from Organisation to ProposedOrganisation it will be better if you add a method to Organisation instead of adding a control flag (it's called control coupling )

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, I'll do this. Thank you!

@OlenaCh
Copy link
Contributor Author

OlenaCh commented Jan 14, 2017

@johnnymo87 @Maroo-b looks like the test coverage slightly dropped :(. It appears that there is one line in AcceptProposedOrganisation service (OTHER_ERROR) which currently I have no idea how to hit. Anyway I'll dig deeper into it during the following week.

@Maroo-b
Copy link
Contributor

Maroo-b commented Jan 17, 2017

@OlenaCh usually when writing unit test for a service, we usually prefer not depending on the result of outside this service's (class) methods.
In our case, to test the output for Response::OTHER_ERROR response, the code depends on the result of

InviteUnregisteredUserFromProposedOrg.new(@email, @org).run

So I suggest to stub that method using the following syntax before the expectation:

#create an object that responds to method status,
# other_response.status == Response::OTHER_FAILURE
other_response = double(status: Response::OTHER_FAILURE)

#Now we tell the InviteUnregisteredUserFromProposedOrg to return the other_response object
#InviteUnregisteredUserFromProposedOrg.new(arg1,arg2).run == other_response
#It's possible to use this alternative syntax also:
#allow_any_instance_of(InviteUnregisteredUserFromProposedOrg).to receive(:run).and_return(other_response)
allow(InviteUnregisteredUserFromProposedOrg.to receive_message_chain(:new, :run).and_return(other_response)

You can read more about stub from RSpec docs: https://relishapp.com/rspec/rspec-mocks/v/3-5/docs/basics

By the way @johnnymo87 do you think that we should inject the service: InviteUnregisteredUserFromProposedOrg into the AcceptProposedOrganisation ?

@OlenaCh
Copy link
Contributor Author

OlenaCh commented Jan 17, 2017

@Maroo-b thank you for a tip! :)

@tansaku
Copy link
Contributor

tansaku commented Jan 18, 2017

@OlenaCh we've got a few merge conflicts here now - let me know if you have trouble resolving them

@OlenaCh
Copy link
Contributor Author

OlenaCh commented Jan 19, 2017

@tansaku I've resolved the conflict and committed changes. I'll look for a bug and then commit a fix for it. Thank you!

@Maroo-b
Copy link
Contributor

Maroo-b commented Jan 23, 2017

@OlenaCh there is a failing test, does it pass locally ?

@OlenaCh
Copy link
Contributor Author

OlenaCh commented Jan 23, 2017

@Maroo-b, it also fails locally. It appeared after merging branches, but looks like I've fixed it today :).

@tansaku
Copy link
Contributor

tansaku commented Jan 25, 2017

@OlenaCh great work getting this green!

BTW, we leave the PT tickets in the started state till thinks are actually merged. With the right commit messages the merging of the PR will automatically mark the PT ticket as finished. See https://github.com/AgileVentures/LocalSupport/blob/develop/CONTRIBUTING.md for more details. Even if you don't have the git commits set up to hook into tracker, I can click "Finish" when I merge.

I hope to review and merge soon - I've just got to give priority to premium PRs (over several projects including this one) in the first instance http://www.agileventures.org/pricing so sometimes I get a little backed up :-)

@OlenaCh
Copy link
Contributor Author

OlenaCh commented Jan 25, 2017

@tansaku oh, sorry for inconvenience! In the future I'll keep about tickets in mind. Thank you! I'm awaiting for your review and feedback; simultaneously, I'm going to choose a new ticket to do. When this one will be merged, I'll be able to proceed to the next task :)

@tansaku
Copy link
Contributor

tansaku commented Jan 26, 2017

@johnnymo87 @Maroo-b - if you're all happy with this one I can give it a final review

@tansaku
Copy link
Contributor

tansaku commented Feb 2, 2017

@Maroo-b @johnnymo87 any outstanding issues on this one? I'd like to get it merged in, but am struggling to find time to do the detailed review I'd like to

@johnnymo87
Copy link
Member

Nope, my original +1 still stands.

@Maroo-b
Copy link
Contributor

Maroo-b commented Feb 14, 2017

+1

@tansaku
Copy link
Contributor

tansaku commented Feb 21, 2017

great work @OlenaCh - sorry for delay - I finally got to look through in detail and looks like a big improvement - really appreciate your hard work

@tansaku tansaku merged commit 9f60a38 into AgileVentures:develop Feb 21, 2017
@OlenaCh
Copy link
Contributor Author

OlenaCh commented Feb 23, 2017

@tansaku thank you very much for the feedback - I am very glad that you liked the PR! Looks like I can proceed with new issues! :)

Maroo-b pushed a commit to Maroo-b/LocalSupport that referenced this pull request Mar 19, 2017
* Fixing error flash bug

* Without valid email organization is not accepted

* Cucumber fix

* Solving Code Climate issues - pull AgileVentures#418

* Refactoring flash messages into a service

* Fixing Code Climate issues

* Fixing Code Climate issues 2.0

* Adding new method to Organisation model

* CodeClimate new issue fix

* One more fix for CC issues

* One more fix for CC issues 2.0

* One more fix for CC issues 3.0

* RSpec refactoring

* More RSpec tests for AcceptProposedOrganisation service

* Cucumber fix
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.

4 participants