Skip to content

Feature: manual charge (GEN-5217)#2932

Open
panasetskaya wants to merge 33 commits intodevelopfrom
feat/manual-charge
Open

Feature: manual charge (GEN-5217)#2932
panasetskaya wants to merge 33 commits intodevelopfrom
feat/manual-charge

Conversation

@panasetskaya
Copy link
Copy Markdown
Contributor

@panasetskaya panasetskaya commented Apr 29, 2026

a11y

  • if these are UI changes - check for their accessibility
  • translations
  • merge backend corresponding branch first: link no need, since I added our own feature flag anyway

@panasetskaya panasetskaya changed the title Feat/manual charge Feature: manual charge (GEN-5217) May 4, 2026
@notion-workspace
Copy link
Copy Markdown

# Conflicts:
#	app/apollo/apollo-octopus-public/src/commonMain/graphql/com/hedvig/android/apollo/octopus/schema.graphqls
#	app/core/core-resources/src/androidMain/res/values-sv-rSE/strings.xml
#	app/core/core-resources/src/androidMain/res/values/strings.xml
#	app/core/core-resources/src/commonMain/composeResources/values-sv-rSE/strings.xml
#	app/core/core-resources/src/commonMain/composeResources/values/strings.xml
#	app/feature/feature-payments/src/main/kotlin/com/hedvig/android/feature/payments/PreviewData.kt
#	app/feature/feature-payments/src/main/kotlin/com/hedvig/android/feature/payments/data/MemberCharge.kt
#	app/feature/feature-payments/src/main/kotlin/com/hedvig/android/feature/payments/data/PaymentConnection.kt
#	app/feature/feature-payments/src/main/kotlin/com/hedvig/android/feature/payments/di/PaymentsModule.kt
#	app/feature/feature-payments/src/main/kotlin/com/hedvig/android/feature/payments/overview/data/GetUpcomingPaymentUseCase.kt
#	app/feature/feature-payments/src/main/kotlin/com/hedvig/android/feature/payments/ui/memberpaymentdetails/MemberPaymentDetailsDestination.kt
#	app/feature/feature-payments/src/main/kotlin/com/hedvig/android/feature/payments/ui/payments/PaymentsDestination.kt
#	app/feature/feature-payments/src/main/kotlin/com/hedvig/android/feature/payments/ui/payments/PaymentsPresenter.kt
#	app/navigation/navigation-core/src/commonMain/kotlin/com/hedvig/android/navigation/core/HedvigDeepLinkContainer.kt
@panasetskaya panasetskaya marked this pull request as ready for review May 6, 2026 11:33
@panasetskaya panasetskaya requested a review from a team as a code owner May 6, 2026 11:33
)

val showPaymentsBadge: StateFlow<Boolean> = missedPaymentNotificationServiceProvider
.prodImpl
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Could we here just use provide to get the appropriate impl for if we're in demo mode or not?

Comment on lines +51 to +66
LaunchedEffect(triggerChargeIteration) {
if (triggerChargeIteration>0) {
val currentState = screenState as? ManualChargeUiState.Success ?: return@LaunchedEffect
triggerManualCharge.invoke().fold(
ifLeft = {
screenState = ManualChargeUiState.Failure(it)
},
ifRight = {
screenState = ManualChargeUiState.Success(
manualChargeInfo = currentState.manualChargeInfo,
navigateToSuccess = Unit
)
}
)
}
}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This looks like if someone double-taps the action and triggers this twice then it will be sent twice to the backend, do you believe this is the case? If yes we could try to guard against it either by doing nothing if there's an ongoing request on the fly.

edit:
Thinking about this a bit more the old iteration should be cancelled as the LaunchedEffect key will cancel the previous scope aka cancel the request. This is probably 99% of the time fine, unless it is cancelled right after the request was sent, yet the response is still in the process of coming back.
If we know that the backend can handle these requests as idempotent then this shouldn't be a problem at all. If the backend will get confused by this being called twice then we'd need to solve it either on our end or on the backend at least.

Comment on lines +172 to +173
this?.startsWith("kivra", ignoreCase = true) == true ||
this?.startsWith("invoice", ignoreCase = true) == true -> MemberPaymentChargeMethod.KIVRA
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Kivra and invoice are both just clumped to Kivra, this is because they are both going through Kivra anyway? Is this a safe assumption to make here? I am asking because I am just missing context, not that I believe it's wrong.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

we probably should name MemberPaymentChargeMethod.Kivra as MemberPaymentChargeMethod.Invoice instead too, since Kivra is just one of the Invoice subtypes.
We only have Trustly, Kivra, Unknown now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants