Properties of FieldType 'comment' should be declared computed

Created on 6 May 2019, about 5 years ago
Updated 7 March 2023, over 1 year ago

The comment FieldType defines several properties :

  • status
  • cid
  • last_comment_timestamp
  • last_comment_name
  • last_comment_uid
  • comment_count

Aside from status, all other properties are not meant to be updated from outside Drupal (e.g. through JSON:API or GraphQL), thus they all should be declared as computed property :

    $properties['last_comment_timestamp'] = DataDefinition::create('integer')
      ->setLabel(t('Last comment timestamp'))
      ->setDescription(t('The time that the last comment was created.'))
      ->setComputed(TRUE);

A little bit of background:

When using JSON:API to retrieve, alter (e.g. changing the title) and save back a node that has a field of type comment field, if the application does not take care of "removing" that field before issuing the PATCH request, there's a risk that the update operation is denied because comments have been added/updated on this particular node.

This is because as those properties are not declared as computed, JSON:API checks that user have write access to these, if they were updated. If they don't match because comments were added/updated, it is considered an update and the whole node update request is denied.

๐Ÿ› Bug report
Status

Needs work

Version

10.1 โœจ

Component
Commentย  โ†’

Last updated 2 days ago

Created by

๐Ÿ‡จ๐Ÿ‡ฆCanada garphy

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia Nikhil_110

    Attached patch against drupal 10.1.x

  • Status changed to Needs review over 1 year ago
  • ๐Ÿ‡ท๐Ÿ‡บRussia Niklan Russia, Perm

    Created tests as requested in #7. They show the problem, but they also show that setting read-only to those properties doesn't fix it.

    Maybe my tests have mistakes, I'm newbie in testing, so someone need to review my test logic.

  • ๐Ÿ‡ท๐Ÿ‡บRussia Niklan Russia, Perm

    I set this one to ยซneeds reviewยป because it's needed. It's not clear, does test missing something or read-only property has no effect at all.

    OP is also mentioned:

    When using JSON:API to retrieve, alter (e.g. changing the title) and save back a node that has a field of type comment field, if the application does not take care of "removing" that field before issuing the PATCH request, there's a risk that the update operation is denied because comments have been added/updated on this particular node.

    It sounds that we also need a test case when a comment is added while the host entity is being edited via JSON:API: load host entity โ†’ create a new comment related to this host entity โ†’ PATCH host entity without changing anything.

    I also have, though, that there is another problem that tests shows. The JSON:API returns exact values which were set for read-only properties after PATCH and POST request. I'm not tested this yet, but it sounds like the comment field on host is updated, but statistics will be updated only on a next host entity load from the database. It doesn't update on host entity changes/save.

  • Status changed to Needs work over 1 year ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States smustgrave

    Not sure if this helps but something I learned very recently, working on https://git.drupalcode.org/project/drupal/-/merge_requests/3535, with jsonapi is that the PATCH and GET use the same route and permissions. So if you're treating them separate that could be an issue.

Production build 0.69.0 2024