-
Notifications
You must be signed in to change notification settings - Fork 30
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
moderation: added request type and service #335
moderation: added request type and service #335
Conversation
from invenio_requests.services.user_moderation.user_moderation import UserModeration | ||
|
||
|
||
class UserModerationRequestService: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: why creating a specific service? Is it really needed?
The requests module has been designed to be generic, and each service method accepts a request_type
that should allow you to create/search/do operations on a concrete request type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to go a bit further and implement this service as a Service
, mainly due to permissions and search.
User moderation had custom business logic (e.g. configurable receiver) and I felt it was better to have a tiny service layer.
creator_can_be_none = False | ||
topic_can_be_none = False | ||
allowed_creator_ref_types = ["user"] | ||
allowed_receiver_ref_types = ["user"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default permissions are allowing the creator/receiver to perform actions, see permissions. You will have to override this behaviour and define who can do that, including the read/search of these requests.
You might want to create a new ad-hoc action, similar to administration, so that we can be flexible and delegate the user moderation to a specific set of people. This allows in the future to, for example, have a second line support managing this part.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I need to review permissions in the next iteration. I will implement the actions (accept, decline) and configure the permissions.
About the invenio-administration generator, I tried to use it in user's service but it was not working. Namely, if the generators of an action (e.g. search
) have more than the administration (Administration()
) then it would disappear and raise permission errors. As far as I debugged, this was happening here.
In the end, I am using SystemProcess()
. But I do agree we need to review this and understand if that's good enough for the user moderation actions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you get there, maybe we can discuss it quickly, having a look to some code. In any case, Administration
role must have access to the request, otherwise these users cannot perform searches and see it in the admin panel.
from invenio_requests.services.user_moderation.errors import InvalidCreator | ||
|
||
|
||
def test_request_moderation(app, users, identity_simple): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! When you will have the resources, make sure that you add extensive tests there (we aligned on having more tests at the resource level than service level, when possible), and that you also test permission.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added new tests, both for the resource and service.
5e50125
to
c22ab3d
Compare
1d23eeb
to
a59b49b
Compare
Tests are passing locally. The are failing on CI because it needs another PR (users-resources). |
invenio_requests/customizations/user_moderation/user_moderation.py
Outdated
Show resolved
Hide resolved
4a99ea7
to
06d2472
Compare
06d2472
to
ea87f64
Compare
invenio_requests/customizations/user_moderation/user_moderation.py
Outdated
Show resolved
Hide resolved
invenio_requests/customizations/user_moderation/user_moderation.py
Outdated
Show resolved
Hide resolved
invenio_requests/customizations/user_moderation/user_moderation.py
Outdated
Show resolved
Hide resolved
if creator != system_user_id: | ||
raise InvalidCreator(_("Moderation request creator can only be system.")) | ||
|
||
data = data or {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: Is data
being validated somewhere - e.g in the request_service
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, data
is validated by the requests_service
data = data or {} | ||
|
||
# For user moderation, topic is the user to be moderated | ||
topic = {"user": str(topic)} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: Should the service method hardcode that we want a user and check that the user exists? Might be this is the end-result but not very clear from here, so if the case, then add a comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure I understood the question.
But the requests service resolves the entity if:
- it's a dict (like above) and matches the entity dict signature
- it's an instance of the entity (e.g.
User()
orRole()
).
|
||
# Receiver can be configured, by default send the request to users with moderation role | ||
receiver = {"group": role.name} # TODO to be changed to role id | ||
creator = {"group": role.name} # TODO to be changed to role id |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: Should this be the system user instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered this case, however right now a "system user" is considered to be a "User" entity (only on entity resolve though)-
The user entity resolver is currently resolving both "normal" users and "system" user (system_user_id
), which means that, if the creator entity is "user", then a normal user would also be allowed to be the creator and do things on these type of requests (e.g. read
, update
).
To allow only "system", we might need a "system user" entity resolver that does not resolve regular users.
If this is something we want, I would create an issue and tackle it separately.
ea87f64
to
12c0999
Compare
available_actions = { | ||
"delete": actions.DeleteAction, | ||
"submit": actions.SubmitAction, | ||
"create": actions.CreateAction, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: can we do something like
"create": actions.CreateAction, | |
**RequestType.available_actions, | |
... |
?
12c0999
to
f6920c0
Compare
closes #334
NEEDS: