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

Bug4176 support notifications should include username #427

Merged
merged 1 commit into from
Jun 29, 2013

Conversation

kaberett
Copy link
Contributor

@kaberett kaberett commented Jun 9, 2013

Kareila did most of the work on this; I just copied it over and then got dre to tell me what to do with the one non-cooperative piece!

-- facepalm, branched it off the wrong thing. gimme a sec.

--- fix'd.

category => $sp->{_cat}{catname},
subject => $sp->{subject},
username => LJ::trim( "$show_name" ),
Copy link
Member

Choose a reason for hiding this comment

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

(style) we don't need the quotes around the "$show_name"!

@kaberett
Copy link
Contributor Author

Okay, I managed to reproduce the broken behaviour that Fu was getting, and I think this one ACTUALLY does the trick (in terms of getting plausible test results)!

@afuna
Copy link
Member

afuna commented Jun 20, 2013

Excellent thank you! I'll take a look shortly!

On Wed, Jun 19, 2013 at 6:43 PM, kaberett notifications@github.com wrote:

Okay, I managed to reproduce the broken behaviour that Fu was getting, and
I think this one ACTUALLY does the trick (in terms of getting plausible
test results)!


Reply to this email directly or view it on GitHubhttps://github.com//pull/427#issuecomment-19720261
.

@@ -1081,10 +1088,20 @@ sub work {
$dbr->selectrow_array("SELECT message, type, userid FROM supportlog WHERE spid = ? AND splid = ?",
undef, $sp->{spid}, $a->{splid}+0);

# set up $show_name for this environment
my $show_name;
if ( $posterid eq '0' ) {
Copy link
Member

Choose a reason for hiding this comment

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

nitpick: $posterid is an int here not a string, so I'd strongly prefer "$posterid == 0". What you have works, but it's much clearer re: expectations this way!

Copy link
Member

Choose a reason for hiding this comment

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

(nitpick/idiom)
Oh actually, changed my mind, here's a bit more idiomatic, and hopefully intuitive, way of doing that, with a bit more stringent error-checking (note that this shouldn't be necessary, but LJ::load_userid isn't guaranteed to give us a proper $u object, so it's always best to check!

my $show_name;
if ( $posterid ) {
    my $u = LJ::load_userid ( $posterid );
    $show_name = $u->display_name if $show_name;
}

$show_name ||= $sp->{reqname};

Which basically says: try to get a name from the posterid/user object. If, after all that, we had no show_name still, then use the reqname.

Notifications of new support requests now contain the username or
(for logged-out requests) name provided by user. Notifications of
follow-ups to support requests now contain the username of the
person who left the response. I do not allow for anonymous follow-
ups because as far as I can tell they can't happen.
afuna added a commit that referenced this pull request Jun 29, 2013
Bug4176 support notifications should include username
@afuna afuna merged commit d98e824 into dreamwidth:develop Jun 29, 2013
@afuna
Copy link
Member

afuna commented Jun 29, 2013

Whoo! thank you!

@kaberett
Copy link
Contributor Author

kaberett commented Aug 1, 2013

I broke this. There are bugs. It needs reopening, please, and then I will (attempt to) fix it. ;) (Reopen req arises from discussion w/ Dre.)

I will try to get to this in the next week, but it is 3am & I have a houseguest arriving in 12 hours, so ;)

KNOWN ISSUES:

  • all follow-up notifs contain the username of the OP, not the username of the person who triggered the notif (which I SWEAR I had working right on my hack, idek)
  • we get user-set name rather than actual username, and this is not actually desired behaviour (I've checked in with Kat about this & had her say-so)

@anall
Copy link
Contributor

anall commented Aug 1, 2013

@kaberett Oh, when you said bug I assumed you meant bug. I don't think pull requests can be reopened, so just create a new one.

@kaberett kaberett deleted the bug4176-support-username branch November 7, 2015 22:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants