Hi,
So far, we've only had distinctions between "write" users (reset, add, update, etc.) and "read" users (monitor). For that type of distinction, I would highly recommend making the separation at the database level by adding a separate read-only username/password through MongoDB. This kind of distinction should be robust and we would very much want to take actions to help support this.
However, your use case is about "semi-write" users, i.e. you want users that are able to add/update workflows but also not reset the database. Note that any user that has access to the credentials needed to connect to and write to a MongoDB database (e.g., to add or update workflows) will also have the credentials needed to reset it (e.g., by directly connecting to the Mongo shell and executing a remove() command). So it is very difficult to give real security for "semi-write" cases.
If you'd just like to make it *more difficult* for them to reset the database *unintentionally*, I would say that already there are a couple of checks in place. First, the user needs to enter the current date, and second - if done through the command line and removing more than 10 workflows - they need to also positively confirm a prompt. The point of the "current date" is to help prevent users from accidentally resetting the database by re-running a command or code from their history, i.e. accidentally run some code from a week ago that reset the database and have it destroy everything today.
To go beyond this properly, I think one would really need to build a robust authentication system around the lpad reset command. However, if you have any suggestions that would make things secure enough for you do let us know. There are things like storing an additional reset key/hash in MongoDB that could be also required for a DB reset, but are not particularly secure (anyone with the Launchpad credentials could easily view your key by directly connecting to the database).