Development updates - Buk edit - Morning Glory Bugfest tickets:
Jira Legacy |
---|
server | System Jira |
---|
jqlQuery | filter=14610 |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
| Bulk Bulk Edit Morning Glory Known issues (as of August 9, 2022): - UIBULKED-122 - Implement logic for record counts when items bulk edit is triggered by holdings id
- MODEXPW-203 - "Fail to upload file" error with large amount of Users barcodes
- MODEXPW-202 -Incorrect number of records changed on the confirmation banner
- Performance tests results:
| - 00:11:09.870 --> 00:11:19.920
- Magda Zacharska: The biggest part of the development updates is obviously morning glory. We discovered several issues. Here is a list of those issues. They are highly technical, and not all of them, but most of them. We discovered if someone runs Bulk Edit in the Bugfest and exports EDIFACT, eHondings, Circulation logs, or bursar.
- 00:12:10.950 --> 00:12:13.500
- Erin Nettifee: So something is happening on the export manager side?
- Magda Zacharska: Yes, those jobs were being filed and then not being processed. We discovered there are problems with the concurrency of those records. That's why we spent a significant amount separating those jobs and queuing them and also testing the behavior. What are the limits of the records we can safely process at the same time? So If we, for example, lower the number of records that are being processed, will this eliminate the problem, and what are the safe limits?
- 00:13:16.650 --> 00:13:25.710
- Magda Zacharska: Right now, the safe limits are 2500 user records at the same time and 10,000 records for items. And as I said, some work is still in progress and will need to be released and tested in Bugfest. We have two other environments that we are using for testing. One of them is the performance task force Prokachka (spelling??) test and our Bulk Edit performance testing. So there is a lot of testing happening on this. Do you have any questions?
- 00:14:02.760 --> 00:14:03.600
- Erin Nettifee: So, the Morning Glory release is at the end of the month. Is the goal still to get everything that we had planned into Morning Glory, or are you thinking that we might need to back it out or ...
- Magda Zacharska: The plan is to get this into the Morning Glory. The determination will probably be made by the end of this week if we limit the number of records that can be updated simultaneously.
- Erin Nettifee: Would it be a limit that the app would enforce? Would it be expected that the users would know not to go over this number?
- 00:14:46.560 --> 00:14:46.920
- Magda Zacharska: Most likely, we will ask the user to know, and this will be included in the release notes. And once I have the data, I will definitely make everyone aware.
- Erin Nettifee: Is there anything you think we could have done to catch this before Bugfest? The answer might be no, but I'm just wondering if we might have changed our approach.
- Magda Zacharska: I think the challenge here is the coordination between three development teams. Efforts need to go into the teams that work on eHoldings, and Export and the teams that work on EDIFACT export. Obviously, you know when you look back, you know what the right thing is. We started experimenting with large data pretty early, and as you see, I linked to the performance tests (see links in the left column). If we do only user records, we can easily do 10,000 records, however, if we increase the number, it affects other areas. So we need to be cognizant.
- Magda Zacharska: Regarding the known issues. The first one is "implement logic for record counts when items bulk edit is triggered by holdings id." This is the label when we count the records, how many records were submitted, how many records were (Magda could not open Bugfest) ...
- 00:17:51.630 --> 00:18:02.790
- Magda Zacharska: When we upload the records--in my example, I submitted a list of 10 records, and it states that 10 records match. And here are the 10 records.
- Magda Zacharska: If we submit a Bulk Edit by submitting Holdings UUIDs. I can send a list of two holdings ids and have 10 records matching the search criteria. How we report this on screen is why we have this story, UIBULKED-122. I will bring it up at one of our meetings at some point, and we will discuss what is the best approach.
- 00:18:50.160 --> 00:19:04.470
- Magda Zacharska: The second known issue, MODEXPW-203, is the "'fail to upload file' error with a large amount of Users barcodes," this is happening when we attempt to update approximately 100,000 user record identifiers.
- Magda Zacharska: Since we know we will limit the number in Morning Glory, that is going to move to Nolana, and we will be addressing it in Nolana. The last know issue in the list, MODEXPW-202, is "Incorrect number of records changed on the confirmation banner." I am not comfortable marking it as a known issue, but we don't have the resources to address it.
- 00:19:49.290 --> 00:19:49.830
- Magda Zacharska: Once the update is completed. The preview of records changed displays. But we see in the error counts are zero, and also, the records successfully change is zero. This is happening because UI is not waiting for the back-end to respond. If the user clicks the refresh, the correct number is displayed. This is most likely a known issue for Morning Glory. Any comments or questions?
- Magda Zacharska: Due to the slowness of my machine, I'm not going to open the links to the performance reports. If you are interested, please feel free to follow the links. The most important one is the "combined tests: Combined test for data export worker (Morning Glory), which covers exports of other record types. This is what is the closest to the real-life scenario that those will be executed concurrently, so those are still in progress, but the report started to be created. Any other comments or questions before we move on to reviewing the user acceptance testing feedback?
- 00:22:26.970 --> 00:22:30.030
- Erin Nettifee: I don't have any I don't know if anybody else does feel free to chime in.
|
UAT feedback review - continued from the last meeting | - 00:22:41.970 --> 00:22:54.300
- Magda Zacharska: Okay, so this is the document with the feedback I linked the results of the survey, thank you for putting it together so quickly, and Erin for providing data.
- Erin Nettifee: And thank you, everybody, for participating because we actually got a really good response rate.
- Magda Zacharska: I put together the results.
Image Modified - Magda Zacharska: So column a is what is currently implemented. The properties in bold are those with are displayed by default. Version one is the list of properties that in the survey were selected as the ones that should be included on the landing page. And version two is the fields that will be displayed if we limit the number to the bare minimum. I have to say that I am a little bit confused by the lack of consistency between version one and version two, and I'm not sure how to interpret this.
- 00:24:49.140 --> 00:24:51.600
- Erin Nettifee: There's some consistency there. You can see that the barcode is there, towards the top of both. I think people may think about the types of jobs they would do in version one, and then they may think about the bare minimum they need to identify an item in version two. That would be how I would interpret that. Because if you're talking about identifying an item, you're talking about needing a barcode or an HRID. But the types of jobs I might do with an item, like version one, would include things like loan types and locations and stuff, and that's all pretty close to the top. Actually, I don't know, it seems like version one and version two might be pretty close to each other, except for version one bumps effective location way down. I didn't feel like this is what was in the results. Magda, when did you look at the results?
- Magda Zacharska: I look at the spreadsheet. This is page 11 and page 13. The reason I'm bringing it up is that I believe there is not much consistency between version one and version two, in my opinion, although I may be skewed.
- Erin Nettifee: Jenn, version one was question one in the survey, which essentially is if you were to reorder all of these values, what order would you put them in? And the survey did do that randomly. So the list of columns was presented randomly to people. And so it was put this thing in order. And then version two is question two, and the question essentially was, if we only presented a limited number of values, what would you consider to be the things that would need to be presented?
- 00:27:50.010 --> 00:28:01.380
- NOTE: There was a back and forth between Erin and Magda about how the results of the survey were reported on the spreadsheet and its accuracy. Magda tabled this discussion for now.
- 00:32:25.110 --> 00:32:28.590
- Magda Zacharska: I would like to table this conversation for a moment, I will add the data Erin you pointed out and add one more column in the excel spreadsheet. It does not seem clear-cut. I think there are still a lot of Gray areas. The number of columns and the list of columns being displayed depends on the type of job the user is going to do. If the user wants to update item status, obviously, that is something that would like to be displayed on the first page. But it's the same case for permanent loan types and locations. So, for now, I would propose really leaving the columns as they are. And maybe in later releases, we can come back.
- 00:33:43.500 --> 00:33:52.590
- Erin Nettifee: Yes, I will say that all columns currently available compared to the current implementation were actually pretty close. And so, in my mind, that supports not making immediate changes to this.
- Erin Nettifee: But, I think we should go back and look at the results again and make sure that what came out of the survey is interpreted and make sure we're comparing the right things.
- Magda Zacharska: sounds good. I agree with you. However, I think this conversation about the columns leads to the next problem that was also brought up during the user acceptance testing, the column selection and the persistence of those selections.
- Magda Zacharska: So, for example, how persistent should the selection of the columns be? Should they persist by the user, the session, on the preview of records, on the "are you sure" for, on the confirmation screen? Or should the user have an option to change those columns instead?
- 00:35:56.370 --> 00:35:56.760
- Erin Nettifee: Thomas is saying he would prefer the preference be stored by the user, but there's currently no function for user preferences, which is true. Session is supported and is used in a variety of different places.
- 00:36:20.100 --> 00:36:22.080
- Leeda Adkins: So his session, the amount of time you're logged in is session the Bulk Edit job?
- Erin Nettifee: Session on the RA side is usually the length of time with no activity, if that makes sense, so it's sort of like if there's been no activity for five minutes, time out. There's also an end session button in some Apps.
- Magda Zacharska: So we have new Bulk Edit. That would be the equivalent of a session.
- Erin Nettifee: Okay. So, in that sense, then it would be like preserving it for the duration of the particular Bulk Edit job. To me, that makes sense.
- Leeda Adkins: I think somebody who does these sorts of Bulk Edit jobs wants selections to persist from the preview screen to the final result screen. But then, I think it should just go back down to the minimum amount because I may be doing several iterations of jobs for the project rather than keeping it to a set default.
- 00:37:50.850 --> 00:38:06.990
- Erin Nettifee: Would that experience require you to add the same column for each of those bulk edit jobs if you did not have a default column setting?
- Leeda Adkins: Well, that's true.Erin
- Erin Nettifee: I think in an ideal world, you would store this as a user preference, based on the record type, but there's no user preference system and FOLIO yet, and so session, maybe is the place to start.
- Magda Zacharska: But I want to follow up on this. Let's say FOLIO has the ability to store user preferences. Would that mean that every time the user opens a Bulk Edit for item records, their default set of columns will work, or will it depend on the job type?
- Erin Nettifee: So I would assume in that scenario that I have defaults. I may have five columns as my default, and if I went in and I checked a new column, that persists until I go in and uncheck the box. And then, at that point, I get a new set, so if I end up using it, and then going okay actually, I need to tweak this. I need to add these two columns so that I could do that, and I would just change it.
- Magda Zacharska: So, this, is this was my question, so every time you work on users, you will have those three or four columns that you specify in the settings. Is that something that you would prefer instead of having this driven by the session?
- 00:40:48.720 --> 00:40:53.970
- Magda Zacharska: So, for example, today, I work with the location, and I would like to display all permanent locations and temporary locations as a second column. But tomorrow, I am starting to work on loan type at the first two. Is this a real-life example, is it not how it works?
- Erin Nettifee: That's is, as far as I'm concerned, a real-life example.
- Erin Nettifee: You know, for me, it makes more sense if a system has settings that persist than if they just if they revert, and then I have to go in and check the same things over and over and over again because I think as people do this, they will develop a style of their own or information need. It makes more sense to have a persistent thing that I tweak as I go, rather than having to go in and set it up for each job, which is essentially what session and a session-based would mean, but I think a session-based thing is okay to start. I'm not advocating that we build a user preference system as part of this.
- Magda Zacharska: Most likely not going to happen. But we can do the persistent settings for the session. And my understanding of session persistence is that once you make that selection on the preview of matched records, you see the same columns on the "are you sure" form and the confirmation screen.
- Erin Nettifee: Yes, it would make sense to me that it would be the same columns throughout the job.
- Leeda Adkins: That's more important to me than what it shows for each session.
- Erin Nettifee: So what I hear is a session-based approach. The columns persist throughout the job. When you hit new Bulk Edit, it resets the column order, and then you can go in and tweak the column order for the next job and then ideally, FOLIO will work towards a user preference system that could then be used to help these settings persist per user.
- Magda Zacharska: This is my understanding as well.
- 00:43:35.370 --> 00:43:40.380
- Magda Zacharska: The next question that is on my list is paging through matching records results. Our last meeting touched on the preview showing the top 10 records. It was brought up that 10 records are not enough and that you would like to be able to see the matching records and page through them, something similar to how it is done in inventory, where you get the list of 100 records, and then you page through using previous and next buttons. And we also talked about how this would affect performance; it's easier to return the top 10 records than return 10,000 records, for example. The question I have, I have several questions, but question number one is if let's say, you do the Bulk Edit of 10,000 records. Do you really plan to go through all of them paging through them? How this is done on the large data sets? And where do we draw the line; where is the line where you would not attempt to look to the UI?
- Erin Nettifee: Leeda is saying the current preview shows 10 records, but you have the option to download a CSV of the entire preview, is that correct?
- Magda Zacharska: That is correct. This is how it works.
- Leeda Adkins: Especially if we're getting into performance issues here, that sounds okay to me.
- Magda Zacharska: The issue, I think, is really visible when you have 11 or 12 records, and you get back only 10. What is going on with the other two? This may not have been communicated by me ...
- 00:46:31.920 --> 00:46:34.680
- Erin Nettifee: The chat says people are fine, with a preview of 10 and then a download for more investigation.
- Erin Nettifee: You could increase it to 20 if you feel like that would be helpful. It may be just an artifact of the Bulk Edit use cases we were using where there were really small sets of data.
- 00:46:57.120 --> 00:47:04.620
- Bob Scheier (Holy Cross): I agree that it's fine to just have the download option when you want to see more, but I think the messaging on the screen could be more clear in terms of saying you're viewing is a preview of 10.
- Erin Nettifee: Right, or even if you didn't change the verbiage, you could pop a little question mark that you could hover over to provide a help message. That might be nice too.
- Sara Colglazier: I think it has to be clear that you are seeing just a few, and also, it does make a difference if it's a random 10 or the first 10.
- Magda Zacharska: So my understanding is it is the top 10. So if your list has 11 identifiers, the first 10 will be displayed. However, I need to double-check if the order is not changing
, - because this depends on how the database returns them.
- Sara Colglazier: Going back to the actual numbers. If I have 10,000, obviously, I'm not going to scroll through 10,000. But I do find that 10 is very, very few. I'm used to seeing potentially all of them in Aleph. I could still see my complete preview and scroll through if I wanted to.
- Magda Zacharska: Leeda adds that in Aleph, there is the "do not update the database" option.
- Magda Zacharska: So you have two options of not committing first the preview...
- Sara Colglazier: I just want to finish. I just tend to think 10 to be very few. I think it would be nice if, performance-wise, we could go up to 100. Beyond that, I'm fine with downloading a file.
- Erin Nettifee: Maybe Magda, one of the ways to think about it would be to fill the white space that appears here. Is there a way to say fill the screen?
- 00:51:41.460 --> 00:51:42.660
- Magda Zacharska: So you see the white space here because there are no errors, but then you will have the additional accordion with errors. And this was actually my second question. Should we also show a preview of the top 10 errors? But you have the option of saving the errors as well. Do you want to see all errors, or do you want to see the preview?
- Erin Nettifee: Could we present a download link outside of the action menu? I don't know if there's a UI pattern for that. I get back to what I think Bob was saying earlier. Just saying a preview of records matched the first 10 or something like that. You know, is there a way that we could just make that download more obvious?
- Magda Zacharska: I think we can come back to this additional link maybe later. I don't want to commit to this. I agree, maybe we can change the verbiage on this to make it clear that this is the top can preview. Or if we increase the number to 100 to make it a little bit more user-friendly, that would obviously require scrolling down, and if you have 100 records here and then the errors below that, you would need to scroll down a lot to the bottom of your preview to see if there were errors or not.
- Bob Scheier (Holy Cross): I have a couple of questions. In other software, you sometimes see the option to choose how results you want to see. And then the other is if there's a lot like 100, can we have a tabbed interface in that window that you could tap to see the errors?
- Magda Zacharska: We will come back to these ideas for sure. I think that the simple way right now would be to make the description a little bit
more - clear to state that this is just a preview and state how many records are included. The next step would be to include 100 results and maybe add the paging mechanism to go to the record. But eventually, we will need to draw the line of how many records we are previewing
. 48400:55:52.290 --> 00:55:52770 and485 00:55:53.880 --> 00:56:12.060 Magda Zacharska: Let me take a look at the notes, because we are slowly running out of the time and paging through how many records should be displayed by default we touched this pledging to our list, do we need the earliest or downloading their errors is enough. 486 00:56:20.280 --> 00:56:20.640 part. 48700:56:22.890 --> 00:56:39.090Magda Zacharska: Right now, when there are errors, we also show top 10 and then to see all there's you need to download that do you do you think it's enough - Next on the list: " do we need to page error list, or downloading the list of errors is enough? Any comments?
- ??Say that last part again...
- Magda Zacharska: Right now, when there are errors, we also show the top 10, and then to see all of them, you have to download them. Do you think it's enough, or do you would like to be able to see more as well
.488 00:56:40.320 --> 00:56:43.470 Sara Colglazier : I think they're seeing fewer errors is. 489 00:56:44.130 --> 00:56:45.330 Magda Zacharska: No clinical notes. 49000:56:50.370 --> 00:56:52.500Sara Colglazier : Then i- ?
- Sara Colglazier: I'm more likely to download
and not.49100:56:56.370 --> 00:57:09.060Sara Colglazier : Because - the errors because you know there's an
air so, on - error. On the other, it's more like you're skimming to see if there's something that I didn't think about that is actually
cause - causing a problem that is not an
air.49200:57:10.470 --> 00:57:22.830Sara Colglazier : - error. But some piece of data that I didn't account for in what I was going to do, and so, if I hit submit
to the to the ones- , am I going to affect something that I didn't actually want to
effect.49300:57:23.790 --> 00:57:38.670Sara Colglazier : that's I mean that's very often why I skim through the you know, - affect? That's very often why I skim through the do not update database option that's why I use that all the time in our previous system
, - . I would run it, and then I would just kind of skim through and go
oh.49400:57:39.750 --> 00:57:42.570Sara Colglazier : Man oh - , oh, there's something I didn't think of that.
49500:57:43.110 --> 00:57:51.270Sara Colglazier : And it was really helpful, but on the air - And it was really helpful. But on the errors, you're telling me
oh - there's an error, the machine knows there's an error
so.49600:57:52.680 --> 00:57:54.900Sara Colglazier : - , so I want to download that to look at
anyways.497 00:57:56.610 --> 00:57:57.750 Sara Colglazier : I hope that. 498 00:57:58.620 --> 00:57:59.700 Sara Colglazier : As i'm fine with 10. 499 00:58:00.930 --> 00:58:01.650 Sara Colglazier : It helps. 500 00:58:02.490 --> 00:58:07.710 Magda Zacharska: him, but the other question I have because. 501 00:58:08.850 --> 00:58:16.920 Magda Zacharska: We didn't catch the are you sure form it's also showing the top. 502 00:58:18.030 --> 00:58:27.960 Magda Zacharska: records, but we talk about the preserving the column selection, that if we select on the landing page the columns. 503 00:58:29.040 --> 00:58:30.540 Magda Zacharska: The columns will be. 504 00:58:31.740 --> 00:58:36.270 Magda Zacharska: preserved for are you sure, and for the confirmation screen. 505 00:58:37.560 --> 00:58:40.530 Magda Zacharska: paging to the results of the on the. 506 00:58:41.700 --> 00:58:42.420 Magda Zacharska: On the. 507 00:58:43.650 --> 00:58:53.130 Magda Zacharska: Short form, and I think Sarah, this is the closest to what you are saying, do not commit to the database because, are you sure forum shows you. 508 00:58:53.550 --> 00:59:10.380 Magda Zacharska: This is how the data will look in the database once you make the change, but the changes until you click the button commit changes are not committed, so you can still from this form click cancel and go back. 509 00:59:12.210 --> 00:59:23.070 Magda Zacharska: So should we discuss just the paging to the results on the preview page under are you sure page. 510 00:59:24.510 --> 00:59:33.000 Magda Zacharska: We are out of the time we will be shortly out of the time and Internet minutes so maybe we should come back to this. 511 00:59:38.550 --> 00:59:40.020 Magda Zacharska: Discussion of the. 512 00:59:41.370 --> 00:59:43.050 Magda Zacharska: Of the behavior of are you sure. 513 00:59:44.760 --> 00:59:57.360 Magda Zacharska: form, I just want to mention that something that was brought up during the a user acceptance testing could save and close button was not clear enough that users were not. 514 00:59:58.380 --> 01:00:09.330 Magda Zacharska: sure that they are conducting the changes we make the change so right now, when you when you are on there are you sure form so, for example, before I do here. 515 01:00:11.250 --> 01:00:17.490 Magda Zacharska: Look at it and I change the status to missing, for example. 516 01:00:23.220 --> 01:00:25.110 Magda Zacharska: And this is the Community changes. 517 01:00:26.130 --> 01:00:47.640 Magda Zacharska: Here you can download the files, this is where you see all the records that will be affected the data is not safe in the database just yet you just see this is how it will look once you click commit changes and committing changes. 518 01:00:52.590 --> 01:00:56.970 Magda Zacharska: And here's the data that is already committed and changed. 519 01:01:06.390 --> 01:01:08.490 Magda Zacharska: So should we talk more about the. 520 01:01:11.160 --> 01:01:14.100 Magda Zacharska: about the are you sure form or are you. 521 01:01:15.900 --> 01:01:18.420 Bob Scheier (Holy Cross): i'm wondering why why it's different than the. 522 01:01:20.010 --> 01:01:23.220 Bob Scheier (Holy Cross): preview in terms of the way it displays. 523 01:01:24.360 --> 01:01:28.230 Bob Scheier (Holy Cross): As a separate window versus on the screen. 524 01:01:31.380 --> 01:01:37.410 Magda Zacharska: Because this dish you also an easy way to go back so if you are on the. 525 01:01:40.770 --> 01:01:53.040 Magda Zacharska: We need to start from your bucket is right now, but if you are here, there is no way of going back to the changes right, it is a do you see the problem with the pop up. 526 01:01:53.460 --> 01:01:58.890 Bob Scheier (Holy Cross): window I don't know if maybe if anybody if nobody else was wondering about I just wondered why. 527 01:01:59.940 --> 01:02:14.130 Bob Scheier (Holy Cross): When you're looking at a preview you're looking at it on the screen and then, when you get to the point of seeing the changes that you before you commit you get a pop up window and wondering why it can't when when did normally just be the same. 528 01:02:14.820 --> 01:02:20.520 Magda Zacharska: At least, you have the link directly you don't need to go to the action menu, you can link. 529 01:02:20.610 --> 01:02:20.850 Bob Scheier (Holy Cross): That. 530 01:02:21.090 --> 01:02:21.900 to download it. 531 01:02:23.520 --> 01:02:25.860 Bob Scheier (Holy Cross): Maybe so maybe it should both be like that I don't know. 532 01:02:26.280 --> 01:02:30.030 Magda Zacharska: um and I, you know I don't want to reinvent the ui. 533 01:02:30.540 --> 01:02:32.700 Magda Zacharska: Okay what's some reasons. 534 01:02:32.730 --> 01:02:34.620 Magda Zacharska: That we did it this way. 535 01:02:34.650 --> 01:02:38.820 Magda Zacharska: Okay, I just want to be as easier. 536 01:02:40.170 --> 01:02:43.200 Magda Zacharska: for you to use so if something is prohibitive. 537 01:02:44.220 --> 01:02:50.400 Magda Zacharska: For you being efficient, then we definitely need to be addressing it we are. 538 01:02:51.150 --> 01:02:52.440 Magda Zacharska: One minute after. 53901:02:52.680 --> 01:03:03.750Magda Zacharska: Our time would probably and to the.54001:03:04.980 --> 01:03:17.880Magda Zacharska: Welcome meetingfor the WOLCON Welcome Meeting, please feel free to reach out and bring to my attention, thank you all for your feedback and time, and then i bye bye.541 01:03:18.390 --> 01:03:19.500 Leeda Adkins: Thank you bye. 54201:03:20.040 --> 01:03:20.400Magda Zacharska: |