-
Notifications
You must be signed in to change notification settings - Fork 65
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
Don't always force a rescan when page is refreshed #856
Comments
I've actually thought about this recently, and agree with the idea. When we originally built it to scan on each page load the idea was that since it was only scanning content that changed it would be a very fast update to the content. However, the reality is that it can take a while to get through the content just to check whether changes have occurred. So I like the idea of not waiting for the scan, but that alone isn't sufficient. I think if we disable the auto-scan we need to make it very obvious to run a scan, not just a link hidden in the kebab menu. And it needs to be clear when the last time a scan was made. So maybe we have a bar across the top that says "Last scanned: 10/21/2022" with a "Scan Now" button next to it. If everyone agrees this is a good direction I can claim this. |
@webchuckweb you got my vote! The last scan result status line is really helpful. |
Yeah, that all looks like a good idea and I like the screenshot and the explicit information. I updated my original comment as I think it should scan if there isn't an initial report but just not force a rescan after that. It makes sense to me to move it out of the menu and have it more obvious. |
That all sounds good, maybe we could split this up into two issues? Have just a PR for now to have a configuration option to disable the auto rescan then get this improved UI fix in there. |
UMich decided to put this feature on hold for now. |
I think we thought initially it was a good idea to be able to turn off, especially for working in development mode. But to turn off for everything introduces the new problem where UDOIT would be out of sync with the course. And we didn't test to see what happens if for instance
It seems like having it updated is the ideal. We were thinking it might be better if some better progress indicator was shown to the users similar to the old UDOIT rather than disabling the scan. It might be nice to have this optionally able to be disabled though either on a per course or per instance basis with the UX change as suggested. |
In courses with a lot of content and issues, rescanning can take up to a minute before any user action can take place.
This also can make debugging issues with the tool where large courses are needed for testing more time consuming waiting for the rescan to free up the action. It's seems fine to always run a scan the first time if the course has never scanned content before but shouldn't always run a scan. This is similar to how the previous version of UDOIT ran. A scan can always manually be triggered off of the kebab menu.
I think there should be an config that could either be set in the environment or possibly per course to turn off the auto scan feature, but it ideally would have to check if the course has been scanned at all yet.
I manually disabled this locally for testing a different issue by removing this and resetting the state but a better fix would toggle this.
The text was updated successfully, but these errors were encountered: