Re: Uploaded Avatar issues with http/https in RB 3.0.1

2017-12-15 Thread Christian Hammond 
That was exactly the problem. We're no longer normalizing the casing at the
right place. We'll have a fix in for the next point release (aiming for
Tuesday).

Christian

On Fri, Dec 15, 2017 at 1:37 PM, Christian Hammond  wrote:

> It very well could be. I’ll investigate that possibility.
>
> Christian
>
>
> On Fri, Dec 15, 2017 at 08:11 Peter Hodgson 
> wrote:
>
>> Hi Christian,
>>
>> Interesting, okay,
>>
>> I'm seeing the issue across the board everywhere an avatar is expected,
>> the dashboard, infoboxes, and the user page itself. Instead of the expected
>> gravatar avatar I see the default white silhouette on a grey circular
>> background.
>>
>> Previous examples non-redacted (I didn't really need to).
>>
>> v2.5.17 - working for all ldap users
>> https://secure.gravatar.com/avatar/
>> 483f151626d3ac0ec8a1c5d443dc57ee?s=24&d=mm
>> "
>> width="24" height="24" alt="peter.hodgson" class="gravatar">
>>
>> v3.0.1 - not working for *most *ldap users
>> https://secure.gravatar.com/avatar/
>> 483f151626d3ac0ec8a1c5d443dc57ee?s=24&d=mm
>> "
>> alt="Peter Hodgson" width="24" height="24" srcset="https://secure.
>> gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=24&d=mm
>>  1x,
>> https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57
>> ee?s=72&d=mm
>>  3x,
>> https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57
>> ee?s=48&d=mm
>>  2x"
>> class="avatar">
>>
>> Looking directly at user emails shows up something interesting. I have
>> discovered one ldap user who still has a working gravatar in 3.0.1, his
>> username and email do not consist of Firstname.Lastname and is a lower case
>> abbreviation. Looking at the difference between my user (non working
>> gravatar) and the admin user with my email address (working gravatar) the
>> difference in email address is that the admin one is all lowercase rather
>> than capitalised first letters. None of these email addresses have been
>> changed across versions but it seems none with an upper case letter still
>> work.
>>
>> Case sensitive hashing now perhaps? Seems unlikely.
>>
>> Thanks again,
>> Peter
>>
>> On Thursday, 14 December 2017 20:20:42 UTC, Christian Hammond wrote:
>>
>>> Hi Peter,
>>>
>>> The LDAP code hasn't changed between the releases. When logging in via
>>> LDAP for the first time, a local User entry is created with details coming
>>> from LDAP, but those details aren't re-queried from LDAP later, so a user
>>> that existed in 2.5.17 should have the same details as one in 3.0.1.
>>>
>>> The difference in alt text is just the new template factoring in full
>>> names. I checked the logic for building the hashes, and they seem to be the
>>> same. Can you verify the stored e-mail addresses for those users on both
>>> versions?
>>>
>>> Where are you seeing the bad Gravatars? What shows up in their place?
>>>
>>> Christian
>>>
>>
>>> On Thu, Dec 14, 2017 at 4:04 AM, Peter Hodgson 
>>> wrote:
>>>
 Sorry to be so noisy Christian, I'm now seeing problems with gravatar
 sourced images. The switch to v3x has moved to use a srcset which makes
 sense but the actual links being used have changed.

 At a wild guess it looks like it's related to ldap use, possibly
 different fields being used to generate the gravatar link?

 v2.5.17 - working for ldap users
 https://secure.gravatar.com/avatar/
 330e7f60f1888b8f6e?s=24&d=mm" width="24" height="24"
 alt="peter.hodgson" class="gravatar">

 v3.0.1 - not working for ldap users
 https://secure.gravatar.com/avatar/483f151626d3ac?
 s=24&d=mm" alt="Peter Hodgson" width="24" height="24" srcset="
 https://secure.gravatar.com/avatar/483f151626d3a?s=24&d=mm 1x,
 https://secure.gravatar.com/avatar/483f151626d3a?s=72&d=mm 3x,
 https://secure.gravatar.com/avatar/483f151626d3a?s=48&d=mm 2x"
 class="avatar">

 however the non-ldap admin user which has my email address is still
 working in v3.0.1
 https://secure.gravatar.com/avatar/
 330e7f60f1888b8f6e?s=24&d=mm" alt="admin" width="24"
 height="24" srcset="https://secure.gravatar.com/avatar/
 330e7f60f1888b8f6e?s=24&d=mm 1x, https://secure.gravatar.com/
 avatar/330e7f60f1888b8f6e?s=72&d=mm 3x,
 https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=48&d=mm
 2x" class="avatar">

 I wonder if the alt text changing for the normal users is indicative of
 this change of source fields for the link generation. It's worth noting
 that I haven't changed any ldap settings between the two versions.

 Thanks,
 Peter


 On Wednesday, 13 December 2017 12:57:00

Re: How to set extra_data for review model in RVB3.0?

2017-12-15 Thread Christian Hammond 
That’s definitely the wrong form for it to be sending. It should show up as
“extra_data.veto=1”. You see the same behavior in your extension?

That repro case is helpful. I’m going to dig into that.

Christian


On Thu, Dec 14, 2017 at 22:46 Xy Sui  wrote:

> Hi,
>
> I'm testing the setExtraData in this way now (also to simply the code
> demonstration here)
>
> In reviewboard/static/rb/js/views/reviewDialogView.es6.js, method
> "_saveReview". I added/modified 2 lines inside the 1st block f of
> funcQueue('reviewForm').add:
>
>  *this.model.setExtraData("veto", 1);*
>
> and
>
>  saveFunc.call(this.model, {
>  attrs: ['public', 'shipIt', 'forceTextType',
>'includeTextTypes', 'publishToOwnerOnly','
> *extraData*'],
>
> The expected result is each time one review is saved ,the "veto" field in
> extra_data will be saved as well. And I got the payload in client side is:
>
> api_format=json&public=1&ship_it=false&force_text_type=html&include_text_types=raw%2Cmarkdown&extra_data%5Bveto%5D=1
>
> You could see one param "extra_data[veto]:
> 1" is included inside, while the review resource API doesn't accept it
> because it only accepts 3 forms: extra_data:json, extra_data:json-patch and
> extra_data.xxx
>
> In my payload, the key name with square brackets "[veto]" is not taken as
> correct extra_data fields.
>
> I got the same results in FX and chrome.
>
> Do you have the example code for modified rbstopwatch?
>
>
>
> On Thursday, December 14, 2017 at 7:00:10 PM UTC+8, Xy Sui wrote:
>>
>> Hi,
>>
>> I'm getting desperate after hours' searching/trying... One of our
>> extensions doesn't work now in RVB3.0 because previous setExtraData method
>> doesn't work anymore for review model.
>>
>> In my implementation, I wrote one RB.ReviewDialogHook javascript hook
>> with one customized view. And I would like to save some data in model
>> Review's extraData field. I noticed model Review does have "setExtraData"
>> method, but it's not working...
>>
>> And it looks like the extension rbstopwatch also saves data in
>> extra_data, while the extension is broken in RVB 3.0 as well. So I couldn't
>> find one working example either.
>>
>> Could anybody help? Or anybody has one working example for extra_data
>> setting in javascript?
>>
>> Thanks.
>>
>> BR
>> oswicer
>>
>>
>> --
> Supercharge your Review Board with Power Pack:
> https://www.reviewboard.org/powerpack/
> Want us to host Review Board for you? Check out RBCommons:
> https://rbcommons.com/
> Happy user? Let us know! https://www.reviewboard.org/users/
> ---
> You received this message because you are subscribed to the Google Groups
> "reviewboard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to reviewboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
-- 
Christian Hammond
President/CEO of Beanbag
Makers of Review Board

-- 
Supercharge your Review Board with Power Pack: 
https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: 
https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
--- 
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Uploaded Avatar issues with http/https in RB 3.0.1

2017-12-15 Thread Christian Hammond 
It very well could be. I’ll investigate that possibility.

Christian


On Fri, Dec 15, 2017 at 08:11 Peter Hodgson 
wrote:

> Hi Christian,
>
> Interesting, okay,
>
> I'm seeing the issue across the board everywhere an avatar is expected,
> the dashboard, infoboxes, and the user page itself. Instead of the expected
> gravatar avatar I see the default white silhouette on a grey circular
> background.
>
> Previous examples non-redacted (I didn't really need to).
>
> v2.5.17 - working for all ldap users
> https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=24&d=mm
> "
> width="24" height="24" alt="peter.hodgson" class="gravatar">
>
> v3.0.1 - not working for *most *ldap users
> https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=24&d=mm
> "
> alt="Peter Hodgson" width="24" height="24" srcset="
> https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=24&d=mm
>  1x,
> https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=72&d=mm
>  3x,
> https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=48&d=mm
>  2x"
> class="avatar">
>
> Looking directly at user emails shows up something interesting. I have
> discovered one ldap user who still has a working gravatar in 3.0.1, his
> username and email do not consist of Firstname.Lastname and is a lower case
> abbreviation. Looking at the difference between my user (non working
> gravatar) and the admin user with my email address (working gravatar) the
> difference in email address is that the admin one is all lowercase rather
> than capitalised first letters. None of these email addresses have been
> changed across versions but it seems none with an upper case letter still
> work.
>
> Case sensitive hashing now perhaps? Seems unlikely.
>
> Thanks again,
> Peter
>
> On Thursday, 14 December 2017 20:20:42 UTC, Christian Hammond wrote:
>
>> Hi Peter,
>>
>> The LDAP code hasn't changed between the releases. When logging in via
>> LDAP for the first time, a local User entry is created with details coming
>> from LDAP, but those details aren't re-queried from LDAP later, so a user
>> that existed in 2.5.17 should have the same details as one in 3.0.1.
>>
>> The difference in alt text is just the new template factoring in full
>> names. I checked the logic for building the hashes, and they seem to be the
>> same. Can you verify the stored e-mail addresses for those users on both
>> versions?
>>
>> Where are you seeing the bad Gravatars? What shows up in their place?
>>
>> Christian
>>
>
>> On Thu, Dec 14, 2017 at 4:04 AM, Peter Hodgson 
>> wrote:
>>
>>> Sorry to be so noisy Christian, I'm now seeing problems with gravatar
>>> sourced images. The switch to v3x has moved to use a srcset which makes
>>> sense but the actual links being used have changed.
>>>
>>> At a wild guess it looks like it's related to ldap use, possibly
>>> different fields being used to generate the gravatar link?
>>>
>>> v2.5.17 - working for ldap users
>>> https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=24&d=mm";
>>> width="24" height="24" alt="peter.hodgson" class="gravatar">
>>>
>>> v3.0.1 - not working for ldap users
>>> https://secure.gravatar.com/avatar/483f151626d3ac?s=24&d=mm";
>>> alt="Peter Hodgson" width="24" height="24" srcset="
>>> https://secure.gravatar.com/avatar/483f151626d3a?s=24&d=mm 1x,
>>> https://secure.gravatar.com/avatar/483f151626d3a?s=72&d=mm 3x,
>>> https://secure.gravatar.com/avatar/483f151626d3a?s=48&d=mm 2x"
>>> class="avatar">
>>>
>>> however the non-ldap admin user which has my email address is still
>>> working in v3.0.1
>>> https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=24&d=mm";
>>> alt="admin" width="24" height="24" srcset="
>>> https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=24&d=mm
>>> 1x,
>>> https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=72&d=mm
>>> 3x,
>>> https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=48&d=mm
>>> 2x" class="avatar">
>>>
>>> I wonder if the alt text changing for the normal users is indicative of
>>> this change of source fields for the link generation. It's worth noting
>>> that I haven't changed any ldap settings between the two versions.
>>>
>>> Thanks,
>>> Peter
>>>
>>>
>>> On Wednesday, 13 December 2017 12:57:00 UTC, Peter Hodgson wrote:

 That makes perfect sense. The reason I'd wanted to set it at install
 time is I've been extending a dockerised version, but, as you point out the
 domain method is part of the site_config table so gets migrated with the
 rest of the data. This'll work perfectly.

 I'm happy,

 Thanks again,
 Pe

Re: Uploaded Avatar issues with http/https in RB 3.0.1

2017-12-15 Thread Peter Hodgson 
Hi Christian,

Interesting, okay,

I'm seeing the issue across the board everywhere an avatar is expected, the 
dashboard, infoboxes, and the user page itself. Instead of the expected 
gravatar avatar I see the default white silhouette on a grey circular 
background.

Previous examples non-redacted (I didn't really need to).

v2.5.17 - working for all ldap users
https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=24&d=mm
 
" 
width="24" height="24" alt="peter.hodgson" class="gravatar">

v3.0.1 - not working for *most *ldap users
https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=24&d=mm
 
" 
alt="Peter Hodgson" width="24" height="24" srcset="
https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=24&d=mm
 
 1x, 
https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=72&d=mm
 
 3x, 
https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=48&d=mm
 
 2x" 
class="avatar">

Looking directly at user emails shows up something interesting. I have 
discovered one ldap user who still has a working gravatar in 3.0.1, his 
username and email do not consist of Firstname.Lastname and is a lower case 
abbreviation. Looking at the difference between my user (non working 
gravatar) and the admin user with my email address (working gravatar) the 
difference in email address is that the admin one is all lowercase rather 
than capitalised first letters. None of these email addresses have been 
changed across versions but it seems none with an upper case letter still 
work.

Case sensitive hashing now perhaps? Seems unlikely.

Thanks again,
Peter

On Thursday, 14 December 2017 20:20:42 UTC, Christian Hammond wrote:
>
> Hi Peter,
>
> The LDAP code hasn't changed between the releases. When logging in via 
> LDAP for the first time, a local User entry is created with details coming 
> from LDAP, but those details aren't re-queried from LDAP later, so a user 
> that existed in 2.5.17 should have the same details as one in 3.0.1.
>
> The difference in alt text is just the new template factoring in full 
> names. I checked the logic for building the hashes, and they seem to be the 
> same. Can you verify the stored e-mail addresses for those users on both 
> versions?
>
> Where are you seeing the bad Gravatars? What shows up in their place?
>
> Christian
>
> On Thu, Dec 14, 2017 at 4:04 AM, Peter Hodgson  > wrote:
>
>> Sorry to be so noisy Christian, I'm now seeing problems with gravatar 
>> sourced images. The switch to v3x has moved to use a srcset which makes 
>> sense but the actual links being used have changed.
>>
>> At a wild guess it looks like it's related to ldap use, possibly 
>> different fields being used to generate the gravatar link?
>>
>> v2.5.17 - working for ldap users
>> https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=24&d=mm"; 
>> width="24" height="24" alt="peter.hodgson" class="gravatar">
>>
>> v3.0.1 - not working for ldap users
>> https://secure.gravatar.com/avatar/483f151626d3ac?s=24&d=mm"; 
>> alt="Peter Hodgson" width="24" height="24" srcset="
>> https://secure.gravatar.com/avatar/483f151626d3a?s=24&d=mm 1x, 
>> https://secure.gravatar.com/avatar/483f151626d3a?s=72&d=mm 3x, 
>> https://secure.gravatar.com/avatar/483f151626d3a?s=48&d=mm 2x" 
>> class="avatar">
>>
>> however the non-ldap admin user which has my email address is still 
>> working in v3.0.1
>> https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=24&d=mm"; 
>> alt="admin" width="24" height="24" srcset="
>> https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=24&d=mm 
>> 1x, 
>> https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=72&d=mm 
>> 3x, 
>> https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=48&d=mm 
>> 2x" class="avatar">
>>
>> I wonder if the alt text changing for the normal users is indicative of 
>> this change of source fields for the link generation. It's worth noting 
>> that I haven't changed any ldap settings between the two versions.
>>
>> Thanks,
>> Peter
>>
>>
>> On Wednesday, 13 December 2017 12:57:00 UTC, Peter Hodgson wrote:
>>>
>>> That makes perfect sense. The reason I'd wanted to set it at install 
>>> time is I've been extending a dockerised version, but, as you point out the 
>>> domain method is part of the site_config table so gets migrated with the 
>>> rest of the data. This'll work perfectly.
>>>
>>> I'm happy,
>>>
>>> Thanks again,
>>> Peter
>>>
>>> On Wednesday, 13 December 2017 00:53:57 UTC, Christian Hammond wrote:

 Glad it worked!

 There's no way to set this during install today, but it's something we 
 should add. You can set it