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
Warn when replicating too many docs #5362
Comments
@derickl This looks like the solution for |
This is somewhat related to Server Side Purge #5443 |
Ready for AT on |
There are conflicts on the branch....can you please have a look and resolve them before we merge @dianabarsan ? |
@ngaruko conflicts have been resolved. |
Adds /api/v1/users-info endpoint which returns the number of docs a user will replicate and a warn flag if this number exceeds the recommended limit. when queried as an offline user, returns the requester doc count. when queried as an online user, requires facility_id and role params, plus an optional contact_id param (either GET or POST). is queried as a new step in webapp bootstrapper. When resulting warn flag is truthy, the user has to confirm to actually continue bootstrapping and start replication. Cancelling redirects to login. is queried as a new step in admin user creation/updating. When resulting warn flag is truthy, a warning message is displayed. The admin would need to click on "Submit" the 2nd time to actually create or update the user document. Once an hour, API will log warnings of users that have replicated more than 10 000 docs. Updates webapp bootstrapper to display correct doc count progression, even when interrupted. #5362
Based on the commit comment it seems as though the warning for creating a user is shown after clicking the Submit button, and then Submit would need to be clicked again to proceed. This doesn't seem to be UX pattern we've used elsewhere in the app... how could we reuse a more familiar pattern to users? It seems as though having a warning modal would have been the obvious choice -- but the add/edit user is already in a modal and we don't want to layer modals. We could move the add/edit user modal into the main panel, but that is beyond the scope of this issue. Some other ideas:
I would go with option 2, and replace the Also, since the number of docs is affected by server side purge it would be worth adding a note about that to the user. For instance [edit: clarified wording after getting confirmation that server side purge is considered in the doc count] |
The plan is to update server-side-purge PR so the user-docs API would exclude purged docs and reflect the actual number of docs the user would download - but that required for this PR to be merged first. To summarize, you are requesting that the message should be:
in orange warning style? |
Yes, that is great, thanks. |
The styling changes are available for AT on
Do we want to branch them out to their separate issues so this one would be closed after the styling changes are ATed? |
I think it is less about whether it should be done with the separate issue, and more about if you think they should be included with the same release (3.7). If you think it should, then let's include them. If you think they are high risk for regressions, or extensive time to AT, then we should consider putting them in a future release. |
I think it's ok to use the same issue number and have them all ATed at the same time. Those two PRs look like they're ready for AT, just make sure you document any additional things to test, then we can merge all PRs in one fell swoop! |
The styling changes requested are available for AT on Further, to accomplish point nbr 2 from the issue description (When creating a user through medic-conf query this API and warn (but don't block) the configurer if the doc count is too high): |
Nice work, looks great! |
One more edge case scenario to clarify @dianabarsan . Is this supposed to cover the case of an existing user being updated and assigned to a place with
|
@ngaruko If you're updating the user via the Admin app, then yes. If you're cURL-ing |
…227) Before creating users from csv, calls api/v1/users-info for each user and displays a warning and prompt when API warns about doc counts. medic/cht-core#5362
Updates users-info endpoint to accept multiple roles as a JSON stringified string to support how roles are used in production. #5362
Updates styles so all modal error have alert-danger style. Adds optional error severity to enable warning styles. Updates too-many-docs configuration warning message. #5362
Updates users-info endpoint to accept multiple roles as a JSON stringified string to support how roles are used in production. #5362
Updates styles so all modal error have alert-danger style. Adds optional error severity to enable warning styles. Updates too-many-docs configuration warning message. #5362
Updates users-info endpoint to accept multiple roles as a JSON stringified string to support how roles are used in production. #5362
Updates styles so all modal error have alert-danger style. Adds optional error severity to enable warning styles. Updates too-many-docs configuration warning message. #5362
Updates users-info endpoint to accept multiple roles as a JSON stringified string to support how roles are used in production. #5362
Updates styles so all modal error have alert-danger style. Adds optional error severity to enable warning styles. Updates too-many-docs configuration warning message. #5362
Updates users-info endpoint to accept multiple roles as a JSON stringified string to support how roles are used in production. #5362
Updates styles so all modal error have alert-danger style. Adds optional error severity to enable warning styles. Updates too-many-docs configuration warning message. #5362
Users are trying to replicate more docs sometimes on purpose and sometimes due to misconfiguration. This leads to poor user experience and can impact other users by monopolising server resources. We need to do a better job of communicating the maximum number of recommended docs and also warning when users have been configured incorrectly.
The definition of "too high" is up for debate but I think we should warn at 10,000 docs for now. This can be raised when we improve scalability.
The text was updated successfully, but these errors were encountered: