I don’t envy you being the messenger for that one.
Even being a Brit trained in irony since birth I have to summon up my reserves here …
It’s an ‘interesting’ argument.
As is often the case I don’t know whether to be more worried that someone put it forward in the first place or that someone must have agreed with it.
It really isn’t. It just looks like one.
They want their most inexperienced and naive users to be able to do anything as invasive as send notifications. Skilled developers will only be able to do non-invasive things like turn all the lights off, play loud music, sound sirens, unlock all the doors …
Skilled developers know what they are doing.
In the past, it has happened that developers put source code for people to copy and paste in Groovy, then users would contact customer support asking why certain things happened with their devices (that they didn’t like) and it was due to the configuration they paste on their side, so, in the case of push notifications, a developer could share their code or make a tool to save that code for you with several notifications with profane messages, common users some times don’t even remember what they install and from where, so, how could you help them in that regard?
Sorry, that API isn’t intended for the usage of external users/devs. So, it is not expected that you check the configuration used by an internal tool to paste that same configuration for the one intended for external users/devs.
We are somewhat getting off topic here … not sure how you characterize a “skilled developer”.
You, and Smartthings, have lost my point. You have a JSON API (let’s call it an API) which has different dialects (let’s call incompatibility that), coming from the same company (SmartThings or Samsung). History has proven that this is not the way to offer an interface that builds and grows a community.
This wasn’t so much about “cutting and pasting” as when SmartThings (not a third party developer) provided a consistent interface (JSON) across their multiple tools. In this case, you have not.
The ask is the same. If SmartThings believes in and intends to support the JSON syntax, then it behooves them to support it as a supported, consistent interface. That’s all I ask.
Now there I agree with you. Obviously I am biased given my role in uncorking the bottles but I see the ability to read the Routines and the Smart Lighting rules as a welcome, and indeed desirable, development to promote understanding of what the automations are actually doing in practice rather than making us guess, and an educational aid to understanding use of the Rules API. However I don’t have any expectation that one should be able to port the code across.
That said I do think it would make a lot more sense if there was one version of the Rules in production capable of covering all the requirements without deliberately omitting key functionality from the public Rules API. So it is a difference in emphasis. I am not going to complain that I can’t do something if it isn’t intended that I would know I can’t do it.
Any solution I have wouldn’t involve denying all the end users the tools to do their very best work simply to cause minor inconvenience to the mischief makers who will no doubt continue making mischief.
Personally I’d like to see user account settings that control access to developer tools so users can’t do anything outside of the client apps without being informed of the consequences, and ideally understanding them.