-
Notifications
You must be signed in to change notification settings - Fork 150
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
Form count is not always filtered #687
Comments
Taking this requirement as illustrative:
Going by the book on this (well, reading the DB schema), it looks like the underlying thought is that we should be using each role's permissions to inform the predicates to apply to the form count (to weed out forms in But that presupposes that any actual permissions exist to make the distinction between, in this case, a So let's look at their permission sets:
I don't see any permission here that a Manager has and a Viewer hasn't that could be interpreted as "can list closing forms". But we could bend (= abuse) the semantics of one of the existing permissions, such as If we add permissions, perhaps |
One thing to keep in mind is that we already do this filtering for the form list (e.g., from the /v1/projects/:id/forms endpoint). The goal of this issue is to apply that same filtering to the form count. I think this is where we do the filtering for the form list. I see the verb One option is that we port that filtering logic from the
I wouldn't worry too much about this part right now! If the end result is that you've learned more about extended metadata and roles and this unusual case of filtering, that'll be a useful thing. But also, if all this seems like too much detail, and the requirements aren't clear, feel free to focus on another issue. |
Ah yes you're right, there is prior art of course! Unevenly applied, that's the problem to be addressed for this issue indeed. Now that you've shown me a usage site of a permission (or "verb") called
I suppose the thinking is that it is not necessary - my users don't need |
This hopefully has enough clues about how we ended up with |
Problem description
Central filters the list of forms that it returns to the user based on the user's role on the project. For example:
That's true both on the homepage and on the forms page.
However, this filter is not applied to the
forms
count returned with the extended metadata of the individual project response (on the forms page). Theforms
count always includes all forms.That differs from the
forms
count returned with the project list on the homepage (/v1/projects?forms=true). That count does seem to be filtered. That said, I suspect that if ?forms=true were not specified, then the count would not be filtered (though I haven't confirmed this).To summarize:
forms
formList
andforms
forms
(I think)I don't think we surface the
forms
count in a lot of places in Frontend. If it differs from the form list response on a project page, Frontend will automatically update it to match the form list in order to reduce inconsistency. There is one case I can think of where a Project Viewer would briefly see the non-filtered count. If a Project Viewer navigates to the forms page, then between when they receive the project response and the form list response, they will see the non-filtered count.URL of the page
https://staging.getodk.cloud/#/projects/90
Steps to reproduce the problem
forms
count.forms
count.Expected behavior
The
forms
count should always be filtered.Central version shown in version.txt
The text was updated successfully, but these errors were encountered: