-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Show banner after editing finalized form #5762
Conversation
@alyblenkin do you have any suggestions for the banner text here? I'm linking "Learn more" to https://forum.getodk.org/t/42007. |
@seadowg - what do you think about these options for the banner message? I'm trying to use similar language to the post. |
I really like the first one! Maybe we should say "in the next release"? We're not totally sure whether it will be 2023.4 or 2024.1. "Starting in the next release"? |
@alyblenkin let's go with the second one for now |
@@ -264,8 +264,6 @@ private void logFormEdit(Cursor cursor) { | |||
|
|||
if (status.equals(Instance.STATUS_INCOMPLETE)) { | |||
AnalyticsUtils.logFormEvent(AnalyticsEvents.EDIT_NON_FINALIZED_FORM, formId, formTitle); | |||
} else if (status.equals(Instance.STATUS_COMPLETE)) { | |||
AnalyticsUtils.logFormEvent(AnalyticsEvents.EDIT_FINALIZED_FORM, formId, formTitle); |
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're no longer able to edit finalised forms from Drafts so this would never fire!
But what does "New update" mean? Maybe "In the next version"? I think it helps people plan to have a sense of when things will come into effect. |
Good point. How about "In later releases, finalized forms will no longer be editable."? |
Maybe version means more to normal humans than releases, I'm not entirely sure. |
I was trying to avoid mentioning the release or the version... just a new update they should know about, and then they can go to the link for more info. I agree that some people may want to have the version as a reference, so maybe it's better to be more specific. |
val editedFinalizedForm = | ||
application.getState().get<Boolean>(EDITED_FINALIZED_FORM) ?: false | ||
|
||
if (usingGoogleDrive) { |
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.
Don't we ever need to display both banners at the same time?
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.
We decided that we'd just show the Google Drive one if both apply. From the issue:
Google Drive banner should be shown if they're both applicable
|
||
public abstract static class AppStateKeys { | ||
|
||
public static final String EDITED_FINALIZED_FORM = "editedFinalizedForm"; |
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.
One thing to consider: maybe this should be placed in AppState
class. I'm not sure if keeping constant used in different parts of the app and different functionalities in one class is still a good idea.
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.
Yeah I'm also not sure about ApplicationConstants
, but it did seem like the right place for this at the moment. Maybe we should look at splitting it up next time we want to add something?
I don't think that keys for AppState
should live in the AppState
class as the keys should be owned by the component/module/package using AppState
. I guess you can think about it like a Map
- it shouldn't need to know anything about the things it stores to do it's job of just storing them.
Is this PR included in the CircleCI apk? #5688 |
I'm not actually sure! I'd need to do some digging. Are you seeing some problems related to that? |
I think not connected with the PR (banner) exactly, rather editing a finalized form but if that PR wasn't included that would explain it. Which version should we compare this PR to? |
The last release (v2023.2.4). |
Just to double check if it's ok:
|
Yeah that's fine! We don't want to tell people off for viewing forms before sending.
Yeah that's ok. |
There is also a part in which we need to test Google Drive project. Do you think it would be ok to test it during the regression testing or it's better to test it in this PR (so this means we would need the released apk build)? |
Let's leave it for regression. |
Tested with Success! Verified on device with Android: 13 Verified cases:
|
Tested with Success! Verified on device with Android: 10 |
Closes #5715
Most of the work to make finalised forms editable had already been done, so this just adds a banner that is displayed after a user edits a finalised form until the next time they launch the app.
What has been done to verify that this works as intended?
New tests.
Why is this the best possible solution? Were any other approaches considered?
Not a lot to discuss here. I ended up storing the state in memory rather than in prefs/on disk so that we didn't have to deal with clearing it later. It also feels natural to me to have this stick around until the next launch and then reappear if there is another finalised form edited.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
There wasn't a lot touched here, so just checking the banner is displayed as expected (and not displayed when it's not expected) should be enough.
Before submitting this PR, please make sure you have:
./gradlew checkAll
and confirmed all checks still pass OR confirm CircleCI build passes and run./gradlew connectedDebugAndroidTest
locally.