Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 12
Next »
Attendees (please add your name):
Magda Zacharska leeda.adkins@duke.edu (OLD ACCOUNT) Erin Nettifee Monica Arnold Christine Tobias Robert Scheier Sara Colglazier Kimie Kester Jackie Magagnosc
Note taker:
Robert Scheier
Meeting Recording:
Discussion:
| Topic | Notes |
|---|
Housekeeping | - Please add your name to the attendees list
- Please state your name while joining the conversation
|
Development updates | - Magda: OK looking at the Scrum Board. There's a lot of progress.
- Magda: We are finishing with differentiating the permissions for the CSV approach for the in-app approach because there will be different paths.
- Magda: Updating items status. This is backend work that is happening. This is for the next feature.
Magda: So hopefully next time we meet, I will be able to show you more of the UI. Magda: We are also working on the karate tests that are executed daily on the backend so we are not introducing any regression.
- Magda in response to a question from Erin about testing: For those that are interested, there are the API backend modules tests, and there is end to end tests for the UI. We completed some of them in the last release. They were executed nightly at some point, but I don't think they're being executed nightly anymore. And there is a requirement for every story we are committing on the UI to have at least 80% of code coverage with unique tests. This is true for the front and the backend as well
|
| Progress bar on uploading files with identifiers | - Magda: I updated the agenda in the last two minutes, because I talked with the developers and they mentioned some behavior on uploading the identifiers especially when the file of identifiers is large, it may take some time and incorrectly display the matched records. We would like to add progress before the preview of matched records screen populates while making sure we have gathered all the records, but without constantly polling which causes some problems. The proposed solution would be a similar progress bar to what is displayed while bulk edit is in progress (displayed below).
- Erin: Okay. So just to give it more time to handle the larger files?
- Magda: Yes. If you are uploading a larger data set, the user will have some visual cue That there is something happening and it’s not just hanging.
- Erin: That makes sense to me. I don't know if anybody else has any particular feedback. I see Leeda is giving a thumbs up. Yeah. As long as we're consistent with the behavior of the other parts of the app, that makes sense to me.
- Magda: Okay, thank you. That would make developers also very happy because we've been struggling with different issues around this area. And I would like to have some solution that is acceptable to the user. And I think it will help once we start moving with larger data sets. the other part on my abdomen that I'm sorry, I skipped the development status and a scrum board.
- Magda: The action button in snapshot is not displaying due to a data polling issue.
|
| Bulk edit - Export Manager jobs | - Magda: I would like to talk about the export manager.
Magda: This is kind of a by-product of the work that we have done on bulk edit because we use the same modules that are being used for data export. Magda: The files used in bulk edit are being logged in the export manager. So for example, when you click on the bulk edit identifiers file, you get the list of the identifiers that were submitted.
Magda: This is a byproduct of what we have done. And we could manage it for additional functionality. Erin: My question would be when you are using bulk edit you do not have to have access to export manager to do the functions that need to be done. Magda: This is valid and a very good point. This is a separate set of permissions that are not included in the bulk edit permissions but it will let you access those files.
- Erin: Does this represent a permission issue or a security issue? People can get downloadable copies of edited files, including user information. When maybe we don't want that to happen.
Bob: And I'm not sure I'm following. It seemed like what you were trying to show is duplicative of what you would get just within the app itself. Magda: Yes. But then you are getting historical data. You will be able to go to the job that was previously executed with a link to the file. Bob: So it is not totally necessary for the user to go here, but someone who had the necessary permissions could come here and see the history. Magda: Exactly. This is not required but rather additional functionality that we will have because we are using the common component. - Magda: What I was thinking is we can also utilize the export log which will provide a little bit more information about, what happened, what the job was, who executed and if something went wrong, what was wrong?
Magda: One more thing I wanted to show. This is example of the useful history when you have failed queries. It shows us what was wrong. This was really nice when I was executing this yesterday. But, if we want to use it, then we need to come up with ideas of how we are going to filter the result. Or do you think we should just hide them because of what Erin said about security issues?
- Erin: My question is would people have access to export manager who would not have access to the user's app or to other places and could potentially end up seeing information that an institution would not want them to.
|
| |
| Bulk edit - query search |
|