Protecting Default Properties

I’ve been thinking that we really need a way of keeping users from casually altering default property sets. No matter how often we tell them not to, the way things are now, some people are going to edit them and then consume support resources when they get overwritten as elements are updated.

At first, I thought we should just make them read-only, but Shaun pointed out that developers of new add-ons need to change them.

I can think of a few of ways to protect them, but I thought I’d start a discussion here in case others had better ideas.

1. We could use the old "Lock for editing" checkbox and provide a way for developers to have it checked by default on install.

2. We could pop up a stern "are you sure" warning when default properties are selected for editing.

3. We could lock them with a hard-to-find system setting that only serious add-on developers would use and, when default properties are selected for editing or deletion, pop up this message: "Default Properties should not be changed. Create a new property set and edit the properties in that set."

I think number 1 is too easy to defeat, since many offenders would be admins and could just uncheck the box. It also does nothing to explain why they’re locked.

Number 2 would drive developers of new add-ons completely nuts, so it’s probably a bad idea.

That leaves number 3. I don’t know how hard it would be to implement, but I think it’s important that we do *something* to protect the default properties from casual meddling.

Comments? Other ideas?

I think there’s a lot of merit to this point. Defaults could in fact just be that: defaults ... any changes you make forces it to an untitled set and if you want to change the defaults, rebuild the package. Definitely merits more discussion.

Quote from: rthrash at Dec 29, 2008, 08:59 AM

I think there’s a lot of merit to this point. Defaults could in fact just be that: defaults ... any changes you make forces it to an untitled set and if you want to change the defaults, rebuild the package. Definitely merits more discussion.

No, defaults will be editable.  It will be up to us to develop permissions to assign to user groups which control whether the user can edit them, or provide some other intuitive interface which conveys the difference for folks that don’t understand what the difference between default properties, property sets, and tag properties are.  Slowing down power users with warning prompts is not acceptable IMO.

Constant warnings are definitely out, but a "lock for editing" checkbox, especially if it locked *everyone* out, would let me protect properties from naive admin users and from my own bumbling and wouldn’t be too much of an inconvenience, IMO, and no one would be required to use it.