Users API #60
Users API #60
Conversation
The users query is now querying over the ClaimAdmin and Officer types. This is not really a clean solution but it is the best that we could make with the existing table structures without breaking everything else. Be careful not to optimize the graphql query or it would prevent the User dynamic mapping to the actual objects because some of them would be marked as "deferred". The Mutations are not yet part of this commit but will follow shortly.
This requires an update to the Location module.
The "user" in UserMutation was clashing with the operating user.
It is now possible to call the user creation/update method with just the username instead of the exact core_user ID
health_facility_id was of the wrong type and not rendered in the response for InteractiveUser because the field is not a foreign key. Also added roles with a direct rendering rather than through a userRoles intermediate object.
The mutation link to actual objects was performed on the actual object itself. In the case of User, it caused some conflicts with its `__call__` method because _u was not properly initialised from Django itself. So we are now adding _id to the object and passing its id. We still need the object itself to identify the foreign key. UserMutation was also not exposed to GraphQL and the user was not properly linked for the mutation, it was linked to connected user.
This was preventing the delete of users created from the mutations.
OFS-290: fixed bug with performing uuids bulk actions
|
This pull request fixes 1 alert when merging 549ee51 into 1f9a687 - view on LGTM.com fixed alerts:
|
|
This pull request fixes 1 alert when merging 4ccb3f8 into 1f9a687 - view on LGTM.com fixed alerts:
|
|
This pull request fixes 6 alerts when merging 8d26a2c into 1f9a687 - view on LGTM.com fixed alerts:
|
OFS-292: fixing bulk actions with amount/date valid filters
|
This pull request introduces 2 alerts and fixes 6 when merging 70d90d5 into 1f9a687 - view on LGTM.com new alerts:
fixed alerts:
|
|
Weak cryptography warning from LGTM is partly valid (SHA256 is not bad per se) but is for compatibility reasons. |
| on ClaimAdminCode=cu.username | ||
| where cu.claim_admin_id is null; | ||
| """, reverse_sql="") | ||
| ] |
There was a problem hiding this comment.
@dragos-dobre I don't think we need to do anything but modular is using FK for admin/EO (Which makes sense) but if you really want to align legacy then some action are required
| # TODO make a signal to contract module to not break modular approach and | ||
| # not repeat the same code from contract module | ||
|
|
||
| status_notified = [1, 2] |
There was a problem hiding this comment.
These numbers are difficult to understand. What is their meaning? Should you create meaningful constants and use them here?
Add the various Users APIs