Skip to content

customObjectId does not work with beforeSave triggers #6733

Description

@buitanloc

Issue Description

  • customObjectId does not work with beforeSave triggers.

Steps to reproduce

  • Turn on flag allowCustomObjectId on ParseServer
  • Try to create a GameScore object with customObjectId objectId1 (from Android or iOS)
  • Back to ParseServer, add beforeSave trigger for GameScore with empty body / function.
  • Try to create the second GameScore object with customObjectId objectId2 (from Android or iOS)

Expected Results

  • Received 2: GameScore objects with customObjectId: objectId1, objectId2.

Actual Outcome

  • The first object has objectId is objectId1 while the second object has random id like this sMTH8Sq6jl

Environment Setup

  • Server

    • parse-server version: 4.2.0
    • Operating System: N/A
    • Hardware: N/A
    • Localhost or remote server? (AWS, Heroku, Azure, Digital Ocean, etc): The problem happens on both localhost and Heroku
  • Database

    • MongoDB version: 4.2.7
    • Storage engine: N/A
    • Hardware: N/A
    • Localhost or remote server? (AWS, mLab, ObjectRocket, Digital Ocean, etc): The problem happens on both localhost and mLab

Activity

  1. JeromeDeLeon commented on Jun 14, 2020

    @JeromeDeLeon
    Contributor

    I think inside PServer, It uses JS-SDK and in it, it is not yet implemented. parse-community/Parse-SDK-JS#1097

  2. added
    type:bugImpaired feature or lacking behavior that is likely assumed
    on Jul 7, 2020
  3. ArkeshGKalathiya commented on Sep 18, 2020

    @ArkeshGKalathiya

    Any update on this? I am having same issue. I was saving custom object ids from express app, and it was working fine. And as soon as I add beforeSave trigger, it started discarding the provided custom ids, and stored objects with newly generated ids by parse.

  4. stale commented on Nov 8, 2020

    @stale

    This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

  5. felix-ht commented on Feb 2, 2021

    @felix-ht

    I can confirm - we have the same issue

  6. bdevore17 commented on Feb 2, 2021

    @bdevore17
    Contributor

    Same!

  7. felix-ht commented on Feb 2, 2021

    @felix-ht

    @JeromeDeLeon

    So i found the reason and a solution.
    getResponseObject calls _getSaveJSON this in turn removes the objectId.

    A simple solution would be to add this to the resolver of getResponseObject . This fixes the issue - as it adds the id back if it is missing from modified object!

    if (triggerType === Types.beforeSave && config.allowCustomObjectId && parseObjectJson.objectId) {
            object.object.objectId = parseObjectJson.objectId
    }

    another option would the to just remove _getSaveJSON if allowCustomObjectId is set. This should be fine as this is not called if a before save trigger ist not set, so removing it will probably not have any side effects. Checking ensures that it would change stuff in cases where the current codebase is already broken.

     if (request.triggerName === Types.beforeSave && !config.allowCustomObjectId) {
        response['object'] = request.object._getSaveJSON();
      }
  8. JeromeDeLeon commented on Feb 5, 2021

    @JeromeDeLeon
    Contributor

    It would be better if you could create a PR for this to further discuss this. @felix-ht

  9. dplewis commented on Feb 24, 2021

    @dplewis
    Member

    allowCustomObjectId has been added to the JS SDK and merged with the server.

    #7222

    I'll try to do a PR to fix this issue.

  10. canyousayyes commented on Mar 3, 2021

    @canyousayyes

    We countered the same issue and glad to know the bug fix has been merged. Any plans to release this fix in the soon future?

  11. lsmilek1 commented on Apr 25, 2021

    @lsmilek1
    Contributor

    +1 - Any plans to release this fix in the soon future?

  12. gtzinos commented on Jan 13, 2022

    @gtzinos

    any update on this?

  13. mtrezza commented on Jan 13, 2022

    @mtrezza
    Member

    The first step would be to open a PR and demonstrate the issue with a failing test. From there, we can look for a fix.

  14. added a commit that references this issue on May 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    type:bugImpaired feature or lacking behavior that is likely assumed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions