briefcase
briefcase copied to clipboard
Regression - The user sees the status and active details button only for newest pulled/pushes forms
Software versions
Briefcase master - REGRESSION Java v1.8 Operating system: Ubuntu, macOS, Windows
Problem description
The user sees the status and active details button only for newest pulled/pushes forms
Steps to reproduce the problem
- The user selects few forms and pulls/pushes
- The user selects other forms and pulls/pushes
- The user sees status and details button only for forms from the second pull/push
1.10.1 | master first pull | master second pull |
---|---|---|
![]() |
![]() |
![]() |
Expected behavior
The user should see the status and active details button for all pulled/pushed/exported forms
Thanks, @mmarciniak90! I think this one requires a little bit of discussion. I'm tagging @yanokwa and @dcbriccetti.
Now the detail window of all forms gets cleaned every time you start a new operation. Before that, you couldn't know which form you pulled/pushed last and lines from previous operations on the same form were present too.
This was made some versions ago and we can bring back the old behavior if we want. No problem :)
I think it's OK that the status gets reset on each operation, but it's not great that you can't click through to see the old messages.
Dunno how reasonable this is, but is it easy to leave the log button enabled and then only update the status of the most recent?
That said, I don't feel strongly about any of this...
Dunno how reasonable this is, but is it easy to leave the log button enabled and then only update the status of the most recent?
Is that:
- Clean all rows of the "Push Status" column
- Leave the detail button enabled with any content it had before
?
I mean, clean all rows before a new push status. And yes, leave the detail enabled with any content it had before.
A simple (and probably superficial) solution might be to delete line statusHistory.setLength(0) from method clearStatusHistory() in class org.opendatakit.briefcasel.model.FormStatus.java. This will clear "success" after each pull/push while leaving detailed status intact for all pulls/pushes.
Hi, @hc02ca, thanks for joining the conversation!
I think you're right, but we should also make sure the UI cleans all those table cells once the user clicks on Pull.
We could even mark the start of a new pull with a new message in the status history to help reading the details.
In pull status, how about “Retrieving…” as it retrieves and then either “Success” or “Failed” when it’s finished.
In the corresponding Status History, how about “Forms are ready for use” if it’s a success.
In the corresponding Status History, how about “Forms were not retrieved. “ if it failed along with more details.
Possible reasons it failed: (Maybe)
-
Server connection was lost translated to “Server connection was lost. Try pulling forms again”
-
Internet connection was unstable translated to “Check your internet connection. Try pulling forms again.”
-
Packets were lost on internet translated to “Forms may have been large. Try pulling forms again.”
-
Permission was denied by server translated to “Server denied connection. Check to see if url, user login and password were correct”
-
Error XYZ happened translated to “Error XYZ occurred. Contact support with log for help.”
etc…
As a non-technical user, I would not want to see a a long message if it failed. I would not be interested in knowing if chunk 1 was processed correctly.
If the log status icon stays bold when there is detailed status in it, it would not be necessary to state which pull was the newest, as only the new pull will finish with either “Success” or “Failed” In the Pull Status column.
Thanks, @hc02ca! All the information we're gathering in this issue is super valuable.
We've been working on improving the way Briefcase gives user feedback and handles log messages, and the things you're pointing out are clearly something we need to take care of. For example, all the details from your last screenshot should go into the log file instead of that dialog.
At this moment we're able to make small improvements but actually fixing this across the board will take some time.
In any case, we're working on improving the way Briefcase pulls and pushes forms, and we will take the change to tweak the messages on the details dialog
IntelliJ no longer runs briefcase. It's able to run Validate though. Any ideas?
There has to be something wrong with your particular IntelliJ project setup. I use it every day and I can launch Briefcase with no problem.
Maybe try with the File > Invalidate cache / Restart option
When you mean clear the UI did you mean to call refresh() on it? Like the below code:
In PullPanel.java class:
view.onAction(() -> { view.setWorking(); view.refresh(); //redraw table forms.forEach(FormStatus::clearStatusHistory); // delete line statusHistory.setLength(0) in method
// pulling action starts below
new Thread(() -> source.ifPresent(s -> pullJobRunner = s.pull(
forms.getSelectedForms(),
appPreferences.getBriefcaseDir().orElseThrow(BriefcaseException::new),
appPreferences.getPullInParallel().orElse(false),
false,
appPreferences.getResumeLastPull().orElse(false),
Optional.empty()
))).start();
});
I'm sorry, @hc02ca... I think I need more context to understand what you're asking. Can you point me to the line where I'm using "clear the UI"
@ggalmazor
When you said "make sure the UI cleans all those table cells once the user clicks on Pull." did you mean clean all cells under
-
pull status column (3rd column)
-
detailed status column (4th column)
before a pull?
Or did you mean clean all cells under ALL four columns before a pull?
Hi @ggalmazor. Can you provide clarification to above question. Thanks!
Hi, @hc02ca! Sorry for the delay of my answer. I haven't had the chance to deal with Briefcase lately.
When you said "make sure the UI cleans all those table cells once the user clicks on Pull." did you mean clean all cells under
- pull status column (3rd column)
- detailed status column (4th column)
Yes, I think that's what we're proposing as a fix.
This is from class org.opendatakit.briefcase.model.FormStatus.java If the form is not selected and there is detailed status info, clear only status (3rd column) for that entry. Otherwise, for all other options, clear 3rd and 4th column.
public synchronized void clearStatusHistory() {
if ( isSelected != true && statusHistory.length() != 0){
statusString = "";
} else {
statusString = "";
statusHistory.setLength(0);
}
}
The first pull is for Farmer Registration_NEW form.
The second pull is for Pear form, however, Farmer Registration form's detailed status button is still bold because it still holds the logged entry from the first pull.
This work the same way for pushing forms as org.opendatakit.briefcase.ui.push.PushPanel.java also accesses org.opendatakit.briefcase.model.FormStatus.java
What do you think @ggalmazor ?
This is looking good to me, @hc02ca :) Let's tag @yanokwa in case he has some feedback to give about it.
I'd suggest some minor changes to the example code you've posted, tough
public synchronized void clearStatusHistory() {
statusString = "";
if (isSelected || statusHistory.length() == 0)
statusHistory.setLength(0);
}