Lock account #5564

[aka001]

No description provided.

[houndci-bot]

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

[aka001]

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

[svbergerem]

@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.

[houndci-bot]

cannot assign to a keyword

[aka001]

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

[aka001]

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.

[jhass]

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

[aka001]

@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.

[jhass]

You should be able to use https://github.com/plataformatec/devise/blob/master/lib/devise/models/lockable.rb#L59

[houndci-bot]

Line is too long. [111/80]

[jhass]

@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.

[jhass]

I think using else here would be clearer

[aka001]

Updated

[svbergerem]

here is an unresolved conflict

[aka001]

@svbergerem Resolved. Thanks.

[jhass]

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

[aka001]

I have squashed the commits.

[jhass]

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]

@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.

[jhass]

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 ;)

[jhass]

It's not about replacing this call.

[aka001]

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

[jhass]

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.

[aka001]

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

[jhass]

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.

[aka001]

I have updated the pr.

[jhass]

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

[aka001]

True that. I have updated the pr.

[jhass]

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

[aka001]

Done.

[jhass]

No need for the stray private either.

[aka001]

Updated.

[jhass]

Thank you!

[Flaburgan]

Nice work @aka001 thank you!

[aka001]

:)