Re: Extra whitespace in Review boxes

[Peter Hodgson]

Great, thanks Christian, I know nothing is ever as simple as it seems to 
begin with.
Peter

On Sunday, 28 January 2018 02:39:06 UTC, Christian Hammond wrote:
>
> The extra space above the Reply button isn’t intentional. We can surely 
> tidy that up.
>
> The extra space around the diff is sort of almost an illusion, kinda. It’s 
> really space allocated for the diff header/footer/expansion controls, but 
> we use some CSS magic to squash those so that we can slide then back into 
> position when hovering over the diff, without impacting layout on the page. 
> In 2.5, hovering would expand and push page content down, which slowed down 
> the page briefly and made scrolling pretty rough whenever the page scroll 
> caused the cursor to land over the diff. The header needs to expand into 
> its allocated position on the page, which is why that gap is there.
>
> The one at the top though is completely fixable, so we’ll poke at that.
>
> Christian
>
>
> On Fri, Jan 26, 2018 at 04:18 Peter Hodgson <peterb@gmail.com 
> > wrote:
>
>> Hi,
>>
>> Is the extra whitespace in the review-comment box in v3 intentional? It 
>> seems like a lot of wasted space and extra scrolling on review pages with 
>> lots of small individual reviews. I've attached a picture of the difference 
>> I'm seeing between v2.5.17 and v3.0.2. It looks like there is extra spacing 
>> in general but I think it's most noticeable at the top of the review.
>>
>> Thanks as always for your excellent product,
>> Peter
>>
>>
>> -- 
>> 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 
>> "Review Board Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to reviewboard...@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 
"Review Board Community" 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.

Extra whitespace in Review boxes

[Peter Hodgson]

Hi,

Is the extra whitespace in the review-comment box in v3 intentional? It 
seems like a lot of wasted space and extra scrolling on review pages with 
lots of small individual reviews. I've attached a picture of the difference 
I'm seeing between v2.5.17 and v3.0.2. It looks like there is extra spacing 
in general but I think it's most noticeable at the top of the review.

Thanks as always for your excellent product,
Peter


-- 
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 
"Review Board Community" 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

[Peter Hodgson]

Sounds good to me, thank you.

On Friday, 15 December 2017 22:27:34 UTC, Christian Hammond wrote:
>
> 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 <chri...@beanbaginc.com 
> > wrote:
>
>> It very well could be. I’ll investigate that possibility.
>>
>> Christian
>>
>>
>> On Fri, Dec 15, 2017 at 08:11 Peter Hodgson <peterb@gmail.com 
>> > 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=24d=mm
>>>  
>>> <https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=24d=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=24d=mm
>>>  
>>> <https://secure.gravatar.com/avatar/483f151626d3ac?s=24d=mm>" 
>>> alt="Peter Hodgson" width="24" height="24" srcset="
>>> https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=24d=mm
>>>  
>>> <https://secure.gravatar.com/avatar/483f151626d3a?s=24d=mm>
>>>  1x, 
>>> https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=72d=mm
>>>  
>>> <https://secure.gravatar.com/avatar/483f151626d3a?s=72d=mm>
>>>  3x, 
>>> https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=48d=mm
>>>  
>>> <https://secure.gravatar.com/avatar/483f151626d3a?s=48d=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 <peterb@gmail.com> 
>>>> 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?
>>>>>
>>>>&

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

[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=24d=mm
 
<https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=24d=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=24d=mm
 
<https://secure.gravatar.com/avatar/483f151626d3ac?s=24d=mm>" 
alt="Peter Hodgson" width="24" height="24" srcset="
https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=24d=mm
 
<https://secure.gravatar.com/avatar/483f151626d3a?s=24d=mm> 1x, 
https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=72d=mm
 
<https://secure.gravatar.com/avatar/483f151626d3a?s=72d=mm> 3x, 
https://secure.gravatar.com/avatar/483f151626d3ac0ec8a1c5d443dc57ee?s=48d=mm
 
<https://secure.gravatar.com/avatar/483f151626d3a?s=48d=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 <peterb@gmail.com 
> > 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=24d=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=24d=mm; 
>> alt="Peter Hodgson" width="24" height="24" srcset="
>> https://secure.gravatar.com/avatar/483f151626d3a?s=24d=mm 1x, 
>> https://secure.gravatar.com/avatar/483f151626d3a?s=72d=mm 3x, 
>> https://secure.gravatar.com/avatar/483f151626d3a?s=48d=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=24d=mm; 
>> alt="admin" width="24" height="24" srcset="
>> https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=24d=mm 
>> 1x, 
>> https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=72d=mm 
>> 3x, 
>> https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=48d=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 201

Re: Site-root being applied twice to links sent in emails in upgraded 3.0.1 install

[Peter Hodgson]

"Possibly related but it seems that comments on existing reviews aren't 
generating emails." - Disregard this, chrome remembering my 
Username/Password was autopopulating those fields in the email settings 
page which got picked up when I saved something else. My bad.

On Thursday, 14 December 2017 11:23:40 UTC, Peter Hodgson wrote:
>
> Hi Christian,
>
> No problem, that's the price of progress. Is there somewhere else I should 
> be looking for these known bugs before reporting them and adding noise?
>
> Possibly related but it seems that comments on existing reviews aren't 
> generating emails.
>
> Thanks,
> Peter
>
> On Thursday, 14 December 2017 00:23:50 UTC, Christian Hammond wrote:
>>
>> Hi Peter,
>>
>> That's definitely a regression in 3.0 with subdirectory installs. We have 
>> a fix in progress already, and will be shipping that in 3.0.2. Sorry for 
>> the trouble!
>>
>> Christian
>>
>> On Wed, Dec 13, 2017 at 4:11 PM, Peter Hodgson <peterb@gmail.com> 
>> wrote:
>>
>>> Hi,
>>>
>>> I am in the position of emails being generated with the site config 
>>> applied twice eg. The below from a mail.
>>>
>>> “This is an automatically generated e-mail. To reply, visit: 
>>> https://reviewboard.redacted.com/ReviewBoard//ReviewBoard/r/237/“
>>>
>>> This is the same for the diff link in the email but I can’t find 
>>> anywhere else it happens, ie. all links on the review page/info boxes work.
>>>
>>> One consideration that could be how I got here is that I did a fresh 
>>> site install of v3 against the v2 DB, letting it perform the evolutions 
>>> then. Could that be relevant?
>>>
>>> Thanks in advance,
>>> Peter
>>>
>>> --
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Christian Hammond
>> President/CEO of Beanbag <https://www.beanbaginc.com/>
>> Makers of Review Board <https://www.reviewboard.org/>
>>
>

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

[Peter Hodgson]

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=24d=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=24d=mm; 
alt="Peter Hodgson" width="24" height="24" 
srcset="https://secure.gravatar.com/avatar/483f151626d3a?s=24d=mm 
1x, https://secure.gravatar.com/avatar/483f151626d3a?s=72d=mm 3x, 
https://secure.gravatar.com/avatar/483f151626d3a?s=48d=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=24d=mm; 
alt="admin" width="24" height="24" 
srcset="https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=24d=mm 
1x, https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=72d=mm 
3x, https://secure.gravatar.com/avatar/330e7f60f1888b8f6e?s=48d=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 automatically using the set-siteconfig 
>> management command:
>>
>> rb-site manage /path/to/sitedir set-siteconfig -- 
>> --key=site_domain_method --value=https
>>
>> Hopefully you aren't needing to create site directories often. If you're 
>> scaling out or moving servers, you want to copy the site directory and run 
>> rb-site upgrade, instead of installing a new site directory, as some 
>> important state will otherwise change.
>>
>> Christian
>>
>> On Tue, Dec 12, 2017 at 1:54 AM, Peter Hodgson <peterb@gmail.com> 
>> wrote:
>>
>>> Hi Christian,
>>>
>>> Thanks very much, that was it exactly, the general settings page had the 
>>> url as http. The avatars are now working great.
>>>
>>> Is that setting generated from the --domain-name parameter of rb-site 
>>> install? I presume there's no way to set that on install?
>>>
>>> Thanks again,
>>> Peter
>>>
>>> On Saturday, 9 December 2017 20:56:14 UTC, Christian Hammond wrote:
>>>>
>>>> Hi Peter,
>>>>
>>>> Thanks!
>>>>
>>>> This looks like it might be setting-related, so let's start there. Can 
>>>> you tell me if the Admin UI -> General Settings page lists the URL of the 
>>>> server as using http or https? And is Media URL using a relative path or a 
>>>> URL (and if so, is that using http or https)?
>>>>
>>>> Any uploaded avatar should be referenced based on the Media URL path, 
>>>> so I'd first suspect it to be that. If that's the case, this would also 
>>>> impact file attachments and their thumbnails.
>>>>
>>>> Christian
>>>>
>>>> On Fri, Dec 8, 2017 at 8:23 AM, Peter Hodgson <peterb@gmail.com> 
>>>> wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> Congrats on getting v3 out. I'm a big fan of ReviewBoard, it's 
>>>>> certainly made my life easier and v3 looks great. 
>>>>>
>>>>> An issue I've having is uploaded avatar images not being shown whilst 
>>>>> using ReviewBoard through https as they are linked as http.
>>>>>
>>>>> Chrome reports them as
>>>>> Mixed Content: The page at '
>>>>> https://redacted.com/ReviewBoard/dashboard/' was loaded over HTTPS, 
>>>>

Re: Site-root being applied twice to links sent in emails in upgraded 3.0.1 install

[Peter Hodgson]

Hi Christian,

No problem, that's the price of progress. Is there somewhere else I should 
be looking for these known bugs before reporting them and adding noise?

Possibly related but it seems that comments on existing reviews aren't 
generating emails.

Thanks,
Peter

On Thursday, 14 December 2017 00:23:50 UTC, Christian Hammond wrote:
>
> Hi Peter,
>
> That's definitely a regression in 3.0 with subdirectory installs. We have 
> a fix in progress already, and will be shipping that in 3.0.2. Sorry for 
> the trouble!
>
> Christian
>
> On Wed, Dec 13, 2017 at 4:11 PM, Peter Hodgson <peterb@gmail.com 
> > wrote:
>
>> Hi,
>>
>> I am in the position of emails being generated with the site config 
>> applied twice eg. The below from a mail.
>>
>> “This is an automatically generated e-mail. To reply, visit: 
>> https://reviewboard.redacted.com/ReviewBoard//ReviewBoard/r/237/“
>>
>> This is the same for the diff link in the email but I can’t find anywhere 
>> else it happens, ie. all links on the review page/info boxes work.
>>
>> One consideration that could be how I got here is that I did a fresh site 
>> install of v3 against the v2 DB, letting it perform the evolutions then. 
>> Could that be relevant?
>>
>> Thanks in advance,
>> Peter
>>
>> --
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Christian Hammond
> President/CEO of Beanbag <https://www.beanbaginc.com/>
> Makers of Review Board <https://www.reviewboard.org/>
>

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

[Peter Hodgson]

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 automatically using the set-siteconfig 
> management command:
>
> rb-site manage /path/to/sitedir set-siteconfig -- 
> --key=site_domain_method --value=https
>
> Hopefully you aren't needing to create site directories often. If you're 
> scaling out or moving servers, you want to copy the site directory and run 
> rb-site upgrade, instead of installing a new site directory, as some 
> important state will otherwise change.
>
> Christian
>
> On Tue, Dec 12, 2017 at 1:54 AM, Peter Hodgson <peterb@gmail.com 
> > wrote:
>
>> Hi Christian,
>>
>> Thanks very much, that was it exactly, the general settings page had the 
>> url as http. The avatars are now working great.
>>
>> Is that setting generated from the --domain-name parameter of rb-site 
>> install? I presume there's no way to set that on install?
>>
>> Thanks again,
>> Peter
>>
>> On Saturday, 9 December 2017 20:56:14 UTC, Christian Hammond wrote:
>>>
>>> Hi Peter,
>>>
>>> Thanks!
>>>
>>> This looks like it might be setting-related, so let's start there. Can 
>>> you tell me if the Admin UI -> General Settings page lists the URL of the 
>>> server as using http or https? And is Media URL using a relative path or a 
>>> URL (and if so, is that using http or https)?
>>>
>>> Any uploaded avatar should be referenced based on the Media URL path, so 
>>> I'd first suspect it to be that. If that's the case, this would also impact 
>>> file attachments and their thumbnails.
>>>
>>> Christian
>>>
>>> On Fri, Dec 8, 2017 at 8:23 AM, Peter Hodgson <peterb@gmail.com> 
>>> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> Congrats on getting v3 out. I'm a big fan of ReviewBoard, it's 
>>>> certainly made my life easier and v3 looks great. 
>>>>
>>>> An issue I've having is uploaded avatar images not being shown whilst 
>>>> using ReviewBoard through https as they are linked as http.
>>>>
>>>> Chrome reports them as
>>>> Mixed Content: The page at 'https://redacted.com/ReviewBoard/dashboard/' 
>>>> was loaded over HTTPS, but requested an insecure image '
>>>> http://redacted.com/ReviewBoard/media/uploaded/avatars/p/pe/peter.hodgson__xyz.jpg'.
>>>>  
>>>> This request has been blocked; the content must be served over HTTPS.
>>>>
>>>> My position is possibly complicated by the RB server being behind a 
>>>> reverse proxy but I've had no other similar issues.
>>>>
>>>> Thanks in advance,
>>>> Peter
>>>>
>>>> -- 
>>>> 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...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> -- 
>>> Christian Hammond
>>> President/CEO of Beanbag <https://www.beanbaginc.com/>
>>> Makers of Review Board <https://www.reviewboard.org/>
>>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Christian Hammond
> President/CEO of Beanbag <https://www.beanbaginc.com/>
> Makers of Review Board <https://www.reviewboard.org/>
>

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

[Peter Hodgson]

Hi Christian,

Thanks very much, that was it exactly, the general settings page had the 
url as http. The avatars are now working great.

Is that setting generated from the --domain-name parameter of rb-site 
install? I presume there's no way to set that on install?

Thanks again,
Peter

On Saturday, 9 December 2017 20:56:14 UTC, Christian Hammond wrote:
>
> Hi Peter,
>
> Thanks!
>
> This looks like it might be setting-related, so let's start there. Can you 
> tell me if the Admin UI -> General Settings page lists the URL of the 
> server as using http or https? And is Media URL using a relative path or a 
> URL (and if so, is that using http or https)?
>
> Any uploaded avatar should be referenced based on the Media URL path, so 
> I'd first suspect it to be that. If that's the case, this would also impact 
> file attachments and their thumbnails.
>
> Christian
>
> On Fri, Dec 8, 2017 at 8:23 AM, Peter Hodgson <peterb@gmail.com 
> > wrote:
>
>> Hi guys,
>>
>> Congrats on getting v3 out. I'm a big fan of ReviewBoard, it's certainly 
>> made my life easier and v3 looks great. 
>>
>> An issue I've having is uploaded avatar images not being shown whilst 
>> using ReviewBoard through https as they are linked as http.
>>
>> Chrome reports them as
>> Mixed Content: The page at 'https://redacted.com/ReviewBoard/dashboard/' 
>> was loaded over HTTPS, but requested an insecure image '
>> http://redacted.com/ReviewBoard/media/uploaded/avatars/p/pe/peter.hodgson__xyz.jpg'.
>>  
>> This request has been blocked; the content must be served over HTTPS.
>>
>> My position is possibly complicated by the RB server being behind a 
>> reverse proxy but I've had no other similar issues.
>>
>> Thanks in advance,
>> Peter
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Christian Hammond
> President/CEO of Beanbag <https://www.beanbaginc.com/>
> Makers of Review Board <https://www.reviewboard.org/>
>

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

Uploaded Avatar issues with http/https in RB 3.0.1

[Peter Hodgson]

Hi guys,

Congrats on getting v3 out. I'm a big fan of ReviewBoard, it's certainly 
made my life easier and v3 looks great. 

An issue I've having is uploaded avatar images not being shown whilst using 
ReviewBoard through https as they are linked as http.

Chrome reports them as
Mixed Content: The page at 'https://redacted.com/ReviewBoard/dashboard/' 
was loaded over HTTPS, but requested an insecure image 
'http://redacted.com/ReviewBoard/media/uploaded/avatars/p/pe/peter.hodgson__xyz.jpg'.
 
This request has been blocked; the content must be served over HTTPS.

My position is possibly complicated by the RB server being behind a reverse 
proxy but I've had no other similar issues.

Thanks in advance,
Peter

-- 
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: RB 2.0.17 - Interdiff fails to highlight deleted code

[Peter Hodgson]

Excellent, that sounds good Christian,

Thanks for the reply,
Peter

On Thursday, 6 July 2017 12:14:07 UTC+1, Christian Hammond wrote:
>
> Thanks, Peter. There's still bugs here, and I've spent a lot of time 
> reworking the algorithms to fix these. I'm not ready to ship any of that 
> code yet, though. Needs further tweaking and testing. Having test cases 
> like these really help with that, and I'll add the files to my regression 
> tests.
>
> Christian
>
> On Wed, Jul 5, 2017 at 9:20 AM, Peter Hodgson <peterb@gmail.com 
> > wrote:
>
>> Hi Chris,
>>
>> I've now replicated this with a very simple example.
>>
>> The original file is attached as LICENSE.
>>
>> I added a char and committed the change reflected in rb40.patch and 
>> created the review request (that file is created via the download patch 
>> link)
>>
>> I then committed a change removing the line starting with the word 
>> LIABILITY and updated the review request, the full diff of which is the 
>> file rb40_v2.patch (again created via the download patch link).
>>
>> To define the issue again:
>> orig - v2 Shows the correct diff, showing both the char addition and line 
>> removal
>> orig - v1 Shows the correct diff, showing just the line change
>> v1 - v2Is nonsense, the diff claims "This file contains only 
>> whitespace changes" and shows the last 5 lines of the rev1 file vs the last 
>> four of the rev2 file. It does not highlight the missing lines.
>>
>> I understand this is an old thread, if I don't hear back in a couple of 
>> days I'll raise it afresh.
>>
>> Many thanks,
>> Peter
>>
>>
>> On Wednesday, 5 July 2017 16:35:28 UTC+1, Peter Hodgson wrote:
>>>
>>> Hi Chris,
>>>
>>> I just came across this same bug in 2.5.12 exactly as described by Paul 
>>> so I'm presuming it wasn't fixed.
>>>
>>> What files do you need to debug this? I'll see if I can reproduce this 
>>> without distributing our actual codebase.
>>>
>>> Thanks,
>>> Peter
>>>
>>> On Tuesday, 30 June 2015 22:37:02 UTC+1, Christian Hammond wrote:
>>>>
>>>> Hi Paul, 
>>>>
>>>> We recently fixed a bug like this, but perhaps there's another issue 
>>>> somewhere. 
>>>>
>>>> In order to diagnose this, I'll need to have original copies of the 
>>>> affected files, as well as both diffs. I won't be able to diagnose without 
>>>> those, unfortunately. 
>>>>
>>>> Christian  
>>>>
>>>> --   
>>>> Christian Hammond - chri...@beanbaginc.com   
>>>> Review Board - https://www.reviewboard.org   
>>>> Beanbag, Inc. - https://www.beanbaginc.com 
>>>>
>>>> -Original Message- 
>>>> From: Paul Fee <paul@gmail.com> 
>>>> Reply: revie...@googlegroups.com <revie...@googlegroups.com>> 
>>>> Date: June 30, 2015 at 4:02:10 AM 
>>>> To: revie...@googlegroups.com <revie...@googlegroups.com>> 
>>>> Subject:  RB 2.0.17 - Interdiff fails to highlight deleted code 
>>>>
>>>> > Hi all, 
>>>> >   
>>>> > I'm using ReviewBoard 2.0.17 and see unexpected behaviour in the diff 
>>>> > viewer. 
>>>> >   
>>>> > Steps to reproduce: 
>>>> >   
>>>> > 1. Change a few files (I'm using SVN) 
>>>> > 2. rbt post   
>>>> > 3. Publish review 
>>>> > 4. Delete a group of lines from one of the files already changed. 
>>>> > 5. rbt post -r   
>>>> > 6. Publish review 
>>>> > 7. Review entire diff: http://reviewboard/r/9581/diff/2/ - Result: 
>>>> PASS 
>>>> > 8. Review first interdiff: http://reviewboard/r/9581/diff/1/ - 
>>>> Result: PASS 
>>>> > 9. Review second interdiff: http://reviewboard/r/9581/diff/1-2/ - 
>>>> Result: 
>>>> > FAIL 
>>>> >   
>>>> > In the second interdiff, RB states that the file contains only 
>>>> whitespace 
>>>> > changes, this is incorrect as lines have been deleted. 
>>>> >   
>>>> > Expanding the entire file, the contain on the left and right diff 
>>>> panels is 
>>>> > correct, I can see that the deleted lines have gone, however they're 
>>>> not 
>>>> > highlighted in red as expected. 
>&g

Re: RB 2.0.17 - Interdiff fails to highlight deleted code

[Peter Hodgson]

Hi Chris,

I've now replicated this with a very simple example.

The original file is attached as LICENSE.

I added a char and committed the change reflected in rb40.patch and created 
the review request (that file is created via the download patch link)

I then committed a change removing the line starting with the word 
LIABILITY and updated the review request, the full diff of which is the 
file rb40_v2.patch (again created via the download patch link).

To define the issue again:
orig - v2 Shows the correct diff, showing both the char addition and line 
removal
orig - v1 Shows the correct diff, showing just the line change
v1 - v2Is nonsense, the diff claims "This file contains only whitespace 
changes" and shows the last 5 lines of the rev1 file vs the last four of 
the rev2 file. It does not highlight the missing lines.

I understand this is an old thread, if I don't hear back in a couple of 
days I'll raise it afresh.

Many thanks,
Peter


On Wednesday, 5 July 2017 16:35:28 UTC+1, Peter Hodgson wrote:
>
> Hi Chris,
>
> I just came across this same bug in 2.5.12 exactly as described by Paul so 
> I'm presuming it wasn't fixed.
>
> What files do you need to debug this? I'll see if I can reproduce this 
> without distributing our actual codebase.
>
> Thanks,
> Peter
>
> On Tuesday, 30 June 2015 22:37:02 UTC+1, Christian Hammond wrote:
>>
>> Hi Paul, 
>>
>> We recently fixed a bug like this, but perhaps there's another issue 
>> somewhere. 
>>
>> In order to diagnose this, I'll need to have original copies of the 
>> affected files, as well as both diffs. I won't be able to diagnose without 
>> those, unfortunately. 
>>
>> Christian  
>>
>> --   
>> Christian Hammond - chri...@beanbaginc.com   
>> Review Board - https://www.reviewboard.org   
>> Beanbag, Inc. - https://www.beanbaginc.com 
>>
>> -Original Message- 
>> From: Paul Fee <paul@gmail.com> 
>> Reply: revie...@googlegroups.com <revie...@googlegroups.com>> 
>> Date: June 30, 2015 at 4:02:10 AM 
>> To: revie...@googlegroups.com <revie...@googlegroups.com>> 
>> Subject:  RB 2.0.17 - Interdiff fails to highlight deleted code 
>>
>> > Hi all, 
>> >   
>> > I'm using ReviewBoard 2.0.17 and see unexpected behaviour in the diff 
>> > viewer. 
>> >   
>> > Steps to reproduce: 
>> >   
>> > 1. Change a few files (I'm using SVN) 
>> > 2. rbt post   
>> > 3. Publish review 
>> > 4. Delete a group of lines from one of the files already changed. 
>> > 5. rbt post -r   
>> > 6. Publish review 
>> > 7. Review entire diff: http://reviewboard/r/9581/diff/2/ - Result: 
>> PASS 
>> > 8. Review first interdiff: http://reviewboard/r/9581/diff/1/ - Result: 
>> PASS 
>> > 9. Review second interdiff: http://reviewboard/r/9581/diff/1-2/ - 
>> Result: 
>> > FAIL 
>> >   
>> > In the second interdiff, RB states that the file contains only 
>> whitespace 
>> > changes, this is incorrect as lines have been deleted. 
>> >   
>> > Expanding the entire file, the contain on the left and right diff 
>> panels is 
>> > correct, I can see that the deleted lines have gone, however they're 
>> not 
>> > highlighted in red as expected. 
>> >   
>> > I don't think this is related to caching as the following steps had no 
>> > effect, the second interdiff consistently shows the same result. 
>> >   
>> > * systemctl restart memcached 
>> > * systemctl restart httpd 
>> > * View second interdiff with different browsers (Firefox and Chromium), 
>> > both show same results, hence not a browser cache issue. 
>> >   
>> > I'm running ReviewBoard on CentOS7 using EPEL packages. 
>> >   
>> > Let me know if you need more information to help recreate or fix this 
>> bug. 
>> >   
>> > Thanks, 
>> > Paul 
>> >   
>> > -- 
>> > 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...@googlegroups.com.   
>> > For more options, visit https://g

Re: RB 2.0.17 - Interdiff fails to highlight deleted code

[Peter Hodgson]

Hi Chris,

I just came across this same bug in 2.5.12 exactly as described by Paul so 
I'm presuming it wasn't fixed.

What files do you need to debug this? I'll see if I can reproduce this 
without distributing our actual codebase.

Thanks,
Peter

On Tuesday, 30 June 2015 22:37:02 UTC+1, Christian Hammond wrote:
>
> Hi Paul, 
>
> We recently fixed a bug like this, but perhaps there's another issue 
> somewhere. 
>
> In order to diagnose this, I'll need to have original copies of the 
> affected files, as well as both diffs. I won't be able to diagnose without 
> those, unfortunately. 
>
> Christian  
>
> --   
> Christian Hammond - chri...@beanbaginc.com
> Review Board - https://www.reviewboard.org   
> Beanbag, Inc. - https://www.beanbaginc.com 
>
> -Original Message- 
> From: Paul Fee  
> Reply: revie...@googlegroups.com   >> 
> Date: June 30, 2015 at 4:02:10 AM 
> To: revie...@googlegroups.com   >> 
> Subject:  RB 2.0.17 - Interdiff fails to highlight deleted code 
>
> > Hi all, 
> >   
> > I'm using ReviewBoard 2.0.17 and see unexpected behaviour in the diff 
> > viewer. 
> >   
> > Steps to reproduce: 
> >   
> > 1. Change a few files (I'm using SVN) 
> > 2. rbt post   
> > 3. Publish review 
> > 4. Delete a group of lines from one of the files already changed. 
> > 5. rbt post -r   
> > 6. Publish review 
> > 7. Review entire diff: http://reviewboard/r/9581/diff/2/ - Result: PASS 
> > 8. Review first interdiff: http://reviewboard/r/9581/diff/1/ - Result: 
> PASS 
> > 9. Review second interdiff: http://reviewboard/r/9581/diff/1-2/ - 
> Result: 
> > FAIL 
> >   
> > In the second interdiff, RB states that the file contains only 
> whitespace 
> > changes, this is incorrect as lines have been deleted. 
> >   
> > Expanding the entire file, the contain on the left and right diff panels 
> is 
> > correct, I can see that the deleted lines have gone, however they're not 
> > highlighted in red as expected. 
> >   
> > I don't think this is related to caching as the following steps had no 
> > effect, the second interdiff consistently shows the same result. 
> >   
> > * systemctl restart memcached 
> > * systemctl restart httpd 
> > * View second interdiff with different browsers (Firefox and Chromium), 
> > both show same results, hence not a browser cache issue. 
> >   
> > I'm running ReviewBoard on CentOS7 using EPEL packages. 
> >   
> > Let me know if you need more information to help recreate or fix this 
> bug. 
> >   
> > Thanks, 
> > Paul 
> >   
> > -- 
> > 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...@googlegroups.com .   
> > For more options, visit https://groups.google.com/d/optout. 
> >   
>
>

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