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

Manage and display members (#8) #74

Merged
merged 24 commits into from
Mar 17, 2016
Merged

Manage and display members (#8) #74

merged 24 commits into from
Mar 17, 2016

Conversation

coaxial
Copy link
Contributor

@coaxial coaxial commented Nov 25, 2015

Add a Member model + tests and add it to the admin panel

Review on Reviewable

biography "MyText"
end

end
Copy link
Member

Choose a reason for hiding this comment

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

Ca we correct indentation here please?

@coaxial
Copy link
Contributor Author

coaxial commented Nov 25, 2015

cc @GalkaS

@nicholasjhenry
Copy link
Contributor

@coaxial Would love to merge. Are you up for rebasing with master?

@coaxial
Copy link
Contributor Author

coaxial commented Nov 27, 2015

I'm getting weird conflicts, it looks like unresolved things were committed?

diff --cc app/dashboards/event_dashboard.rb
index 48b312c,715bbe6..0000000
--- a/app/dashboards/event_dashboard.rb
+++ b/app/dashboards/event_dashboard.rb
@@@ -10,28 -10,12 +10,34 @@@ class EventDashboard < Administrate::Ba
    ATTRIBUTE_TYPES = {
      location: Field::BelongsTo,
      id: Field::Number,
 +<<<<<<< HEAD
 +<<<<<<< HEAD
++<<<<<<< HEAD
++=======
++>>>>>>> 359248fe323be0350abb0ebbe192da3c120e431d
      starts_at: Field::DateTime,
      created_at: Field::DateTime,
      updated_at: Field::DateTime,
      title: Field::String,
      introduction: Field::Text,
      conclusion: Field::Text
++<<<<<<< HEAD
 +=======
 +    type: Field::String,
 +    starts_at: Field::DateTime,
 +    created_at: Field::DateTime,
 +    updated_at: Field::DateTime,
 +>>>>>>> #14 : Add events to administrate
 +=======
 +    starts_at: Field::DateTime,
 +    created_at: Field::DateTime,
 +    updated_at: Field::DateTime,
 +    title: Field::String,
 +    introduction: Field::Text,
 +    conclusion: Field::Text
 +>>>>>>> #14 : Add title, introduction, conclusion.
++=======
++>>>>>>> 359248fe323be0350abb0ebbe192da3c120e431d
    }

    # COLLECTION_ATTRIBUTES
@@@ -40,20 -24,10 +46,26 @@@
    # By default, it's limited to four items to reduce clutter on index pages.
    # Feel free to add, remove, or rearrange items.
    COLLECTION_ATTRIBUTES = [
 +<<<<<<< HEAD
++<<<<<<< HEAD
++=======
++>>>>>>> 359248fe323be0350abb0ebbe192da3c120e431d
      :id,
      :title,
      :starts_at,
      :location,
++<<<<<<< HEAD
 +=======
 +    :location,
 +    :id,
 +    :starts_at,
 +<<<<<<< HEAD
 +>>>>>>> #14 : Add events to administrate
 +=======
 +    :title,
 +>>>>>>> #14 : Add title, introduction, conclusion.
++=======
++>>>>>>> 359248fe323be0350abb0ebbe192da3c120e431d
    ]

    # SHOW_PAGE_ATTRIBUTES
@@@ -64,34 -38,17 +76,46 @@@
    # an array of attributes that will be displayed
    # on the model's form (`new` and `edit`) pages.
    FORM_ATTRIBUTES = [
 +<<<<<<< HEAD
++<<<<<<< HEAD
++=======
++>>>>>>> 359248fe323be0350abb0ebbe192da3c120e431d
      :title,
      :introduction,
      :conclusion,
      :starts_at,
      :location,
++<<<<<<< HEAD
 +=======
 +    :location,
 +    :starts_at,
 +<<<<<<< HEAD
 +>>>>>>> #14 : Add events to administrate
 +=======
 +    :title,
 +    :introduction,
 +    :conclusion
 +>>>>>>> #14 : Add title, introduction, conclusion.
++=======
++>>>>>>> 359248fe323be0350abb0ebbe192da3c120e431d
    ]

    # Overwrite this method to customize how events are displayed
    # across all pages of the admin dashboard.
    #
 +<<<<<<< HEAD
++<<<<<<< HEAD
 +  def display_resource(event)
 +     event.title
 +  end
 +=======
 +  # def display_resource(event)
 +  #   "Event ##{event.id}"
 +  # end
 +>>>>>>> #14 : Add events to administrate
++=======
+   def display_resource(event)
+      event.title
+   end
++>>>>>>> 359248fe323be0350abb0ebbe192da3c120e431d
  end

@nicholasjhenry
Copy link
Contributor

@coaxial I was able to rebase this on my machine. Let's me know if you need a hand, happy to help. I didn't see any unresolved commits. Please let me know if you see any.

@benichu
Copy link
Member

benichu commented Dec 1, 2015

@coaxial Would you like us to rebase that branch before merging?
Thanks for your help :)

@nicholasjhenry nicholasjhenry self-assigned this Dec 1, 2015
@nicholasjhenry
Copy link
Contributor

@coaxial and I will work on this tomorrow.

cc @benichu

@nicholasjhenry
Copy link
Contributor

This is ready for review if anybody is up for it.

@cawel
Copy link

cawel commented Dec 2, 2015

Here are a few comments in disguise of a code review:

More important:

  • since the email and name attributes are required to be present at the application level (in the model), I would also enforce that at the database level with non-null db constraints (well, at least for the email).
  • I would add a db unique index for that email column
  • I see that a User has_one :member, and that a Member has_one :user. However, neither model has a foreign key. Fishy ! 🐟

Less important:

  • I think it's more idiomatic to write:
expect(member).to_not be_valid

instead of:

expect(member.valid?).to be false
  • except for the uniqueness validation, it is not necessary to persist the model in order to check for the validation errors. You can do:
member = Member.new(email: nil)
expect(member).to_not be_valid

Terser, and also tests will run faster 🚀

@nicholasjhenry
Copy link
Contributor

To expand on @cawel idiomatic comments:

expect(member).to_not be_valid

can also be written as

expect(member).to be_invalid

Positive expectations/assertions are often a little easier to read.

@cawel
Copy link

cawel commented Dec 2, 2015

Better indeed.

@coaxial
Copy link
Contributor Author

coaxial commented Dec 2, 2015

Thank you for the feedback, much appreciated. We'll work on it tonight with @GalkaS

@cawel
Copy link

cawel commented Dec 2, 2015

@nicholasjhenry should probably jump in before you refactor tonight, as he seemed to have (during the workshop) a clear idea in which db table to put that foreign key (either in 'users' table or 'members' table).

class Member < ActiveRecord::Base
has_many :events
has_many :organizations
has_one :user
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we write a test for this association?

Copy link
Contributor

Choose a reason for hiding this comment

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

@GalkaS I don't test the presence of associations specifically -- higher level tests will verify if this association exists -- i.e the app will blow up pretty quickly when doing a request spec for example.

@nicholasjhenry
Copy link
Contributor

@nicholasjhenry should probably jump in before you refactor tonight, as he seemed to have (during the workshop) a clear idea in which db table to put that foreign key (either in 'users' table or 'members' table).

Sorry I couldn't address this earlier. The foreign key should really be placed on the member. i.e. a member has_one user. The reason for this is that we want to have our dependencies point towards the user class, not the user class having dependencies on other classes in our system. This avoids the user class becoming a god object.

I understand that you placed it on the user as the foreign key in Administrate doesn't support belongs_to relationships out of the box. I have sometime to look at this tomorrow so I will do some investigation on what the solution to this is.

Thank you for taking the time to make this amendment, and again sorry I didn't respond earlier.

@cawel
Copy link

cawel commented Dec 3, 2015

The foreign key should really be placed on the member. i.e. a member has_one user.

Note that based on his explanation, @nicholasjhenry probably meant to write: a member *belongs_to* user.

@nicholasjhenry
Copy link
Contributor

@cawel 👍

@nicholasjhenry
Copy link
Contributor

OK, just shows how confused I was 🙀

The current version of Administrate we have does not support has_one relationships. So moving the foreign_key to members.user_id will work as that will be a belongs_to relationship. Let me know if you're up for changing this. Thank you!

Thanks to @cawel for keeping my associations speak honest.

# Each different type represents an Administrate::Field object,
# which determines how the attribute is displayed
# on pages throughout the dashboard.
ATTRIBUTE_TYPES = {

Choose a reason for hiding this comment

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

Freeze mutable objects assigned to constants.

@sophiedeziel
Copy link
Member

I fully tested the feature on my machine and I fixed stuff in a way that doesn't break anything if deployed.

However, you will notice in app/dashboards/member_dashboard.rb that I commented out the user fields. The reason is because Administrate will raise an error on create, update and show because it needs a user dashboard and controller. The dashboard is there but the controller is missing (the route too).

@coaxial, can you create that part so members can be fully managed and associated to users and to manage the user record too?

ATTRIBUTE_TYPES = {
events: Field::HasMany,
organizations: Field::HasMany,
#user: Field::BelongsTo,

Choose a reason for hiding this comment

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

Missing space after #.

@@ -53,4 +55,5 @@ def self.default_user
def active_for_authentication?
super && email != DEFAULT_USER_EMAIL
end

Choose a reason for hiding this comment

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

Extra empty line detected at class body end.

sophiedeziel added a commit that referenced this pull request Mar 17, 2016
@sophiedeziel sophiedeziel merged commit 20e65e9 into montrealrb:master Mar 17, 2016
@sophiedeziel sophiedeziel deleted the feature/members branch March 17, 2016 21:44
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.

None yet

8 participants