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

Lock account #5564 #5643

Merged
merged 1 commit into from
Feb 19, 2015
Merged

Lock account #5564 #5643

merged 1 commit into from
Feb 19, 2015

Conversation

aka001
Copy link
Contributor

@aka001 aka001 commented Feb 9, 2015

No description provided.

def lock_account
u = User.find(close_account_params)
u.lock_account!
redirect_to user_search_path, notice: t('admins.user_search.account_locking_scheduled', name: u.username)

Choose a reason for hiding this comment

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

Line is too long. [109/80]
Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping.

@aka001 aka001 mentioned this pull request Feb 9, 2015
@@ -7,6 +7,12 @@ def close_account
redirect_to user_search_path, notice: t('admins.user_search.account_closing_scheduled', name: u.username)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@houndci Shall I change the single-quotes here into double-quotes ?

@svbergerem
Copy link
Member

@aka001 We use houndci to check our javascript code. Apparently it also checks the ruby code. We were trying to disable checks for ruby but weren't successful so far. As long as those comments don't inform you about obvious errors you can just ignore them. We aren't enforcing a ruby code style right now.

@@ -456,6 +456,10 @@ def close_account!
AccountDeletion.create(:person => self.person)
end

def lock_account!
self = { :locked_at => Time.now }

Choose a reason for hiding this comment

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

cannot assign to a keyword

@aka001
Copy link
Contributor Author

aka001 commented Feb 10, 2015

@svbergerem Okay. I have updated the pr and squashed the commits. Thanks.

@@ -24,6 +24,9 @@
- unless user.person.closed_account
%li= link_to t('admins.user_search.close_account'), admin_close_account_path(user), method: :post, data: { confirm: t('admins.user_search.are_you_sure') }, class: 'btn btn-danger btn-mini'

- unless user.locked_at
%li= link_to t('admins.user_search.lock_account'), admin_close_account_path(user), method: :post, data: { confirm: t('admins.user_search.are_you_sure_lock_account') }, class: 'btn btn-danger btn-mini'
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I didn't get the use of "admin_close_account_path" which messed up the "lock account" option.
I used the command in main repository to figured out the use of the same:

grep -r "admin_close_account_path" .

but didn't get any result which details the same.
Please help me in figuring it out.

Copy link
Member

Choose a reason for hiding this comment

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

You might want to give http://guides.rubyonrails.org/routing.html a read then.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jhass Thank you for the link. It helped a lot. I have taken the liberty to add the unlock feature.
When admin closes an user account it's "locked_at" field doesn't change, which results in "lock account"/"unlock account" option to be visible in admin's page.
Should we change the design to: "lock account/ unlock account" shouldn't be visible if the user account is locked?
I have attached the screenshot which reflects the same. The users "aka" and "aka_002" 's accounts are closed still the "Unlock Account" option is visible.
screenshot from 2015-02-18 17 17 04

Copy link
Member

Choose a reason for hiding this comment

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

def unlock_account
u = User.find(close_account_params)
u.unlock_account!
redirect_to user_search_path, notice: t("admins.user_search.account_unlocking_scheduled", name: u.username)

Choose a reason for hiding this comment

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

Line is too long. [111/80]

@jhass
Copy link
Member

jhass commented Feb 18, 2015

@aka001 Looks like the rebase went a bit wrong. Let's try this:

git remote add upstream git:://github.com/diaspora/diaspora.git
git fetch upstream
git checkout 5564_lock_account
git rebase -i upstream/develop
# Drop the line with my commit
# Choose squash for the now second line
# Save & quit
# You'll be in some conflicts, git status shows them, once you cleaned them out use git add to mark them resolved, once all are resolved, use git rebase --continue, that might be needed more than one time
git push -f origin 5564_lock_account

# Later, you can edit the last commit with
git commit --amend
git push -f origin 5564_lock_account

Please also add at least one controller test per new route.

@@ -24,6 +24,11 @@
- unless user.person.closed_account
%li= link_to t('admins.user_search.close_account'), admin_close_account_path(user), method: :post, data: { confirm: t('admins.user_search.are_you_sure') }, class: 'btn btn-danger btn-mini'

- unless user.locked_at
%li= link_to t('admins.user_search.lock_account'), admin_lock_account_path(user), method: :post, data: { confirm: t('admins.user_search.are_you_sure_lock_account') }, class: 'btn btn-danger btn-mini'
- if user.locked_at
Copy link
Member

Choose a reason for hiding this comment

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

I think using else here would be clearer

@aka001
Copy link
Contributor Author

aka001 commented Feb 18, 2015

Updated

number: "head" # Do not touch unless doing a release, do not backport the version number that's in master but keep develop to always say "head"
>>>>>>> develop
Copy link
Member

Choose a reason for hiding this comment

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

here is an unresolved conflict

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@svbergerem Resolved. Thanks.

@jhass
Copy link
Member

jhass commented Feb 18, 2015

There's still a bogus commit in here and this is really fine in one commit, no need for 12. See #5643 (comment)

@aka001
Copy link
Contributor Author

aka001 commented Feb 18, 2015

I have squashed the commits.

@@ -19,4 +19,24 @@
end
end

describe '#lock_account' do
it 'queues a job to lock the given account' do
Copy link
Member

Choose a reason for hiding this comment

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

Uh, I should have payed closer attention to this earlier, sorry. This doesn't reflect what the method does and neither what the spec tests for. It does not queue a job, it executes that action directly (which is fine, since it's a single UPDATE query). So please update the wording here, something like "it locks the given account" should be fine.

Remember that you can edit your commit with git commit --amend.

@aka001 aka001 force-pushed the 5564_lock_account branch 2 times, most recently from 96e5527 to 0faaa4a Compare February 18, 2015 22:09
expect(other_user).to receive(:lock_access!)
allow(User).to receive(:find).and_return(other_user)

post other_user.expect(other_user.reload.access_locked?).to be_truthy
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jhass
This line:

other_user.expect(other_user.reload.access_locked?).to be_truthy

returns the error "undefined method `expect' "
Is this the expected behavior? Kindly explain.

Copy link
Member

Choose a reason for hiding this comment

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

Yes it is. expect is not monkey patched onto all objects, it's only available inside the it block. Just drop the other_user. before it, I'm not following what that should express anyway ;)

expect(other_user).to receive(:lock_access!)
allow(User).to receive(:find).and_return(other_user)

post :lock_account, id: other_user.id
Copy link
Member

Choose a reason for hiding this comment

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

It's not about replacing this call.

@aka001 aka001 force-pushed the 5564_lock_account branch 2 times, most recently from 2fd4d40 to 2e18818 Compare February 18, 2015 22:57
@@ -19,4 +19,20 @@
end
end

describe '#lock_account' do
it 'it locks the given account' do
other_user = FactoryGirl.create :user
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jhass Shall I change the "other_user" to "user" ?

Copy link
Member

Choose a reason for hiding this comment

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

I used user over other_user in my example because I found the other_ rather redundant, I didn't get what it would relate to. But I don't care too much either way.

post :lock_account, id: other_user.id
expect(other_user.reload.access_locked?).to be_truthy
post :unlock_account, id: other_user.id
expect(!(other_user.reload.access_locked?)).to be_truthy
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have first locked the account -> tested it -> unlocked it -> tested it. I think this will cover the test case.

Copy link
Member

Choose a reason for hiding this comment

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

The

post :lock_account, id: other_user.id
expect(other_user.reload.access_locked?).to be_truthy

is kind of redundant with the other test, I think a simple other_user.lock_access! is enough.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have updated the pr.

@aka001 aka001 force-pushed the 5564_lock_account branch 2 times, most recently from 72f21bf to a8267ba Compare February 18, 2015 23:34
it 'it unlocks the given account' do
other_user = FactoryGirl.create :user
other_user.lock_access!
expect(other_user.reload.access_locked?).to be_truthy
Copy link
Member

Choose a reason for hiding this comment

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

Just drop this line, that expectation is not part of the scope of this test.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

True that. I have updated the pr.

def unlock_account
u = User.find(params[:id])
u.unlock_access!
redirect_to user_search_path, notice: t("admins.user_search.account_unlocking_scheduled", name: u.username)
end

private
Copy link
Member

Choose a reason for hiding this comment

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

Please drop the method below, we made it obsolete earlier.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

end

private
Copy link
Member

Choose a reason for hiding this comment

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

No need for the stray private either.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated.

@jhass jhass added this to the next-major milestone Feb 19, 2015
@jhass
Copy link
Member

jhass commented Feb 19, 2015

Thank you!

@jhass jhass merged commit 3bb5e78 into diaspora:develop Feb 19, 2015
jhass added a commit that referenced this pull request Feb 19, 2015
@Flaburgan
Copy link
Member

Nice work @aka001 thank you!

@aka001
Copy link
Contributor Author

aka001 commented Feb 19, 2015

:)

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.

5 participants