simonaberry

+1 for allowing user to enter negative sign first

Here is a video explaining the issue https://www.loom.com/share/9744297bacfd41f3bd18e60527f0eacc

@mtrezza I guess it is debatable if it is a bug or not... but the issue stems from the fact that the saveAll call is a **batch** call, so if...

ok - point taken. It's a bug. Just surprised no-one else has reported it in the last ~10 years!

I have had a very quick look at the [batch saving ](https://github.com/parse-community/Parse-SDK-JS/blob/10a2e5b02db62bdb5edd996ff05198cd96d127f5/src/ParseObject.js#L2472) and it think it would be possible to change that logic from using the `'batch'` endpoint to using...

you could argue that the same risk exists that if there is a network interruption during the individual save, you could equally end up with duplicate objects on the server....

@mtrezza yes - I think your summary of the issue above is good and logical. We have already resolved the problem ourselves by building our own error handling logic -...

From https://www.pdflib.com/knowledge-base/pdf-password-security/encryption/ Note that AES-256 is not supported by the native PDF viewers on OS X/macOS (tested up to OS X 10.10.3) and iOS (tested up to iOS 8.1.3)

:-( Tried ePDFVersion15 & ePDFVersion14, but macOs is still not respecting the permissions

unfortunately no - Mac Preview is still not respecting the encryption..... ;-(