Support wildcard classname in cloud triggers

[uzaysan]

New Feature / Enhancement Checklist

• [x] I am not disclosing a vulnerability.
• [x] I am not just asking a question.
• [x] I have searched through existing issues.

Current Limitation

Currently user have to define cloud triggers one by one. If we have a recurring logic inside of cloud trigger, defining triggers become too hard.

Feature / Enhancement Description

We should be able to define one trigger that applies to all class. Unless that class has its own triggers.

Example Use Case

Parse.Cloud.beforeSave("Test", (request) => {
  //this trigger will be executed for only Test class
});

Parse.Cloud.beforeSave("*", (request) => {
  //this trigger will be executed for every class except Test class
});

Alternatives / Workarounds

No known workaround or alternative.

3rd Party References

Its similar to setting SSL sertificates to multiple subdomains.

[mtrezza]

the more options we give the developer, the more chances someone have to make mistakes. (...) using wildcards increase the risk of going wrong, and regex is especially "risky" to use.

Our philosophy is to not add restrictions for all developers of the basis of potential mistakes by some developers. We always aim for versatility. There are other ways (warnings, guidance, etc.) to "help" developers to not make mistakes.

each trigger should be independent and un-releated. (...) You add beforeSave(SomeRandomObject , ... ) and a few months later you decide to add a security trigger to beforeSave(Parse.Object, ...) This new Parse.Object trigger should apply to EVERYTGHING and not have to modify existing triggers.

You would need to refactor. It seems arbitrary to execute triggers on an inheritance order, it may work for some use cases, not for others. Using a holistic inheritance mechanism for triggers is likely the most intuitive and universal approach.