Make it possible to skip triggers

[AurelienVasseur]

Is your feature request related to a problem? Please describe.
When I'm writing tests I would like to be able to skip triggers.
For example, if I do some security check on my triggers I need to match with that on my test, and sometime it's very annoying because the objective is not to test the trigger, but something else. So it will be very useful to skip them.

Describe the solution you'd like
I see 2 major possibilities:

1. Add an option which can be pass (as a context) on actions

object.save( { skip_before_save: true, skip_after_save: true } );

2. Use the context to simulate the skipping

object.save( { context: { skip_before_save: true, skip_after_save: true } } );

Parse.Cloud.beforeSave("myClass", async (request) => {
   if request.context.skip_before_save == false {
      // do some work
   }
});

Parse.Cloud.afterSave("myClass", async (request) => {
   if request.context.skip_after_save == false {
      // do some work
   }
});

The second solution only required that the context can be used on every triggers - #7058 - but it don't really skip the trigger.
So I definitely think that the first one can be the best option (or something else in the same spirit).

[Moumouls]

hi @AurelienVasseur ,
If i understand in your integration test you want to disable some triggers.

Here you have an issue, this kind of feature misconfigured can allow a client SDK to skip triggers, and in 99% of uses cases triggers contain security checks.

I think here it's an OOS (Out Of Scope) issue.

Here i can suggest:

• Check may be the way you organize your code and may be optimize your trigger to avoid running it on every object save, most used methods are : .isNew(), .existed(), .dirty(), .dirtyKeys()

• In your tests to disable some business logic, you should divide the business logic of your trigger and then use common mock utils depending of you test framework (ex: https://jestjs.io/docs/en/mock-functions)

• You can also use master request check on triggers since you can consider that if master key is used you can skip your business logic securely

[mtrezza]

Here you have an issue, this kind of feature misconfigured can allow a client SDK to skip triggers, and in 99% of uses cases triggers contain security checks.

I think here it's an OOS (Out Of Scope) issue.

Generally, according to the overall product strategy we do not a priori dismiss a feature suggestions based on hypothetical developer mistakes. See the discussion about protected fields. The counter argument is that without an implementation, a developer cooks their own implementation which is not examined by the community and therefore potentially less secure.

The strength of Parse Server is to provide a multi-functional tool for a broad range of use cases, so if we can come up with a sound concept, I see this as a possible addition.

[dblythy]

@AurelienVasseur personally, when I want a different response if i'm testing, I use something like:

const args = process.argv || [];
const testing = args.some(arg => arg.includes('jasmine'));
Parse.Cloud.beforeSave("myClass", async ({object}) => {
  if (testing) {
    return object;
  }
});