-
Notifications
You must be signed in to change notification settings - Fork 174
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
Release/1.20.1 #1682
Release/1.20.1 #1682
Conversation
Release/1.20.0
Feature/compose 1.7.1
Release/1.20.0
Fix ItemButton padding for downstate
Making sure an approved message request sets the contact as visible. They could have been set to hidden if the contact had previously sent another message request which was then declined. Upon sending another one we need to make sure the contact is set to visible once that request is approved.
Fix/message request after delete
Release/1.20.0
} | ||
catch (Exception e){} // the above can throw a null exception |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we address the NPE rather than catching it? Like getName() != null
as part of the condition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SessionHero01 Ideally yes but I couldn't be sure which part was returning null here.
Are we sure it is getName()
?
The store seem to think it was here:
lastMessage.getRecipient().getAddress().serialize().equals(
TextSecurePreferences.getLocalNumber(context)))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right there's no clear indication which one is null
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - just potential additions of qaTag
elements if they'll be required, call it as you see fit.
text = stringResource(R.string.recoveryPasswordHidePermanentlyDescription2), | ||
buttons = listOf( | ||
DialogButtonModel( | ||
GetString(R.string.yes), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add button text as qaTag
if req'd?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The qaTag is applied automatically in the AlertDialog base class implementation. It is set to the text of the button there, on all buttons. Is that what you meant?
text = stringResource(R.string.recoveryPasswordHidePermanentlyDescription1), | ||
buttons = listOf( | ||
DialogButtonModel( | ||
GetString(R.string.theContinue), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add button text as qaTag if req'd?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The qaTag is applied automatically in the AlertDialog base class implementation. It is set to the text of the button there, on all buttons. Is that what you meant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I didn't know it got applied from the base. Just querying whether it was something we needed or wanted to add.
Cleaned up the variant outputs for the huawei build Added local signing configs Made sure the output names were formatted properly
v1.20.1
Fixing some strings related crashes
Upgraded to the latest Compose via the latest BOM
Fixed a long press issue that crept back in