Change in behavior for deleting inventory in no mod objects?

The new bugs introduced by the latest round of updates continue to befuddle me (and my customers). One of my flagship products (The SuperFloor) allows the owner to add and delete their own dances. Because I sell it no mod (it is much too complex to sell with mod rights), the user first issues a command which allows anyone to then drop in inventory items and then they can lock it again. The adding of animations still works fine...

The problem is when the owner goes to try to delete the old ones. The dialog pops up saying that deleting the item IS permitted but may break the object blah blah... as it always has. The strange thing is... deleting the item IS NOT permitted any longer as far as I can tell. It vanishes and then reappears in the inventory. These updates are adding so many new bugs that the Lindens' own dialog boxes can't keep up with all of these illogical and undocumented changes. This worked fine for many months.

I hope this is a bug and not a "new feature" which serves only to break long tested and long working items. This Super Floor contains many thousands of lines of code. It took a very long time to develop and test. Your professional developers need to have a reasonable assurance that updates won't make undocumented (often seemingly very random) changes to previously created items. I understand that changes often have unintended effects in large complex platforms, but LL really needs to try to be more careful with stuff like this.

Are the people manually deleting the Animations? or is the script Deleting them? It looks now that A person is not permitted to delete a script even though it says, "Though permitted, deleting inventory may damage the object. Do you want to delete that inventory item?" Then you say yes. Then the Object Shouts!? yes it SHOUTS! "Not permitted to edit this". Looks like we are going to have to add scripts that detele items in the inventory now. I guess No Mod mean No Mod items can be add if AllowInventoryDrop is on. But we don't have AllowInventoryRemoval. So we have to make our own. Or this might be some type of permissions bugs

Yes... that is what is happening. I hope this is just a bug. If not they just changed the behavior of thousands of objects without bothering to document the change, warn of a change, or even update their own (now) nonsensical dialog boxes.

And even stranger... why in the world does the object SHOUT (yes 96 meters!) that message when someone tries to delete an item from an object they own. People who don't know better are going to think that I was the one who programmed such foolish object behavior.

I'm glad you can confirm this behavior for me. Yes, I can modify the script to delete them via command but doing so on such a complex object means updating parsing scripts and the help dialog engine. This also doesn't solve the problem of now having to replace hundreds of dance floors already sold (which were working just fine). This is just further evidence that SL updates are coming much too quickly with far too little testing. (That's assuming it is a bug and not a very poorly thought out "feature".

Okay I did find that you can move the item from the inventory. But not delete. SO that does work.

Really? My customers have reported they can't move them either... they move out but then appear back in when you open the item again. In what way are you able to drag them out? And does this still work if the item being dragged out has copy perms? I think this is what may result in the two different behaviors.

Okay the Item I had placed in there was a No Copy item. if the item has copy permission then you cannot manually delete it. That is sort of messed

That is what I feared. I wonder if I should flag this as a bug. I'm sure many others have noticed this by now. One problem is that so many intentional changes to object behavior and script behavior are undocumented that it is hard to distinguish bugs from new features sometimes. I'd feel more at ease if a Linden could confirm this is a bug and not an intentional change in behavior.

I did report it as a bug and will again in preview. I sometime think Main Grid Bug reports do get ignored sometimes. Well not ignored but with so many bug report comming it can be hard to catagorize every one of them and most likly get missed. Even on the Known issues page. I have found the same Bug reported more than once there. So even they can;t keep track of know issues.

I found this bug listed on the known issues page. (I missed it before.) At least I know it is a bug now. However, it is only given the middle setting for priority. (Major) They list a workaround as simply transfering the item to inventory. I doubt they realize this workaround fails if the item has copy perms. They may bump it up in priority a notch if they become aware of this.