Possible to get a role's permission?
Thinking about this issue, I wondered if granting Drupal's Change own username permission would allow the name field to be in the PATCH.
That led me to thinking about a jDrupal feature:
- Read permissions from the server.
- If changing
nameis disallowed, removenamefrom the User entity beforesave().
That can handled server-side, but having the permission knowledge client-side would also allow the app to improve UX by deactivating Name fields in any UI forms.
@kentr In D7, DrupalGap hooks into the System Connect call, and appends information like this to the JSON results so the app can determine things about the users/roles/permissions. I chose to leave this out of jDrupal as it felt (and is) very heavy.
In D8, there is hook_jdrupal_connect_alter() that can be implemented in a custom Drupal module to add stuff like this to the Connect result. My gut feeling would be to not place this in jDrupal core as it could get heavy. Now that we're more closely tied with npm, maybe we could have a sub package like e.g. npm install jdrupal-user-roles-and-permissions. Some of these addons may need a corresponding Drupal module, and in this case I think it could be a sub module of the D8 jDrupal module because this will likely be a common feature request.
What do you think?
FWIW, I think this issue is related: https://www.drupal.org/node/2631774
Although it is for comments, I'm hoping that someday D8 REST will just let us PATCH JSON objects, and if a protected property is provided, it would just ignore it, rather than rejecting the entire request.
I understand about wanting to keep the code light. A separate module sounds workable.
It probably is related to that d.o issue.
I think it would be helpful if the Drupal (server-side) module is bundled with jDrupal, and would also be helpful to have a note in the jDrupal docs that some fields are protected and either need to be stripped from the entity before a save() (before the PATCH issue is fixed), or will be silently ignored (after the PATCH issue is fixed).
+1 to the server side module being bundled with jDrupal as a sub module
I realize now that you were suggesting bundling them in you earlier comment...
Yup, no problem. Then the npm portion(s) could each be separate packages.