Can't overwrite policy?

[cgrimm013]

While debugging subscriptions, I found that I cannot overwrite an existing policy for a pico without explicitly deleting the policy. Even though our most recent subscription code changes pass all the tests, somehow policies are not included in the tests, which I discovered was breaking the code (I didn't alter the wellknown policy to include some event name changes). When I tried reregistering and reinstalling the subscription ruleset, the updated policy does not get created on an already existing pico. Take a look at this:

This is on the root pico. Essentially, calling engine:newPolicy does not overwrite an existing policy, so the wellknown policy stays the same and doesn't get my new changes. Is this the desired functionality? It registers a new policy per pico under the name, but there is no way to change it save for explicitly calling engine:removePolicy. Maybe we could add an engine:updatePolicy action? How do we restrict developers so they can only update their own policies?

One security hole with this current problem: a ruleset could create a new policy called wellknown that allows every event. Then when subscriptions is installed, it will use the falsified policy instead of its intended one.. Maybe we could have system policies reserved so no one else can make one with the same name and mess something up? (the terminal could log an error for trying to register a policy with a system policy name)

[cgrimm013]

Also, let's say I'm a developer and make some new events or otherwise I want others with that policy to be able to raise. I don't want to have to call removePolicy, then newPolicy, then reissue subscriptions for everyone that had that policy just to be able to make an update to my code..

[b1conrad]

Maybe we need something like wrangler:updatePolicy an event with attributes eci, policy_id which would replace the current policy in the designated channel with the policy_id provided. on success, it would raise wrangler:channel_policy_updated with original attributes and an additional former_policy_id. This would be added to the io.picolabs.wrangler ruleset as a KRL rule. It would require an engine action
(got this from a classic page at https://picolabs.atlassian.net/wiki/spaces/docs/pages/11403288/Managing+Channels )