But really, just being able to say, "set everything in this sucker so I can give it way" would be a huge help.

I have working code that produces a floater window, with options to select the type of inventory effected and options to select the permissions. It works with multiple objects selected and multiple inventory items.

Currently it is limited to :-

• Task inventory only
  That is, it does not set the permissions on top level objects but will set the permissions on the contents of the objects, eg all scripts (including linked prims). But it can handle multiple selections

• No recursion
  Sorry but it does not yet have the ability to open an object inside an object and recuse through

• Only works with in world objects and there inventory not Your inventory

But i' still pretty pleased with the results.

I'm cleaning the code a little but will post a patch soon for ya all to try.

This is the patch as it currently stands. It works for me and allows me to set the Next owner properties of the inventory of selected objects (tasks). It works with multiple selected objects and allows you to specify just the inventory type to change. It works with inventory in child linked prims.

It is possible to set the Next owner properties of the (root) objects on there own (including multiple selections) using the old tools anyway so i have not reimplemented this.

it does not support recursion and cannot open objects within the inventory of the top level objects, but this could be a future addition.

It adds a new option to the tools menu "Set permissions on selected task inventory" which appears next to the reset scripts in selection and friends.

Have fun

m2

• Add the option to change the permissions on the parent prim/object (default to on).
• Why is the Recursive option shown in the screen shot if there is no case where it would be available?
  • An internal dev should add recursion to this feature – there are too many situations where omitting this could cause undesired and destructive behavior:
    • Example: My gun fires a scripted bullet. If I am reading this correctly, the script in the bullet would not be affected by the permissions change.
• A developer must review this code extensively and some major QAing would have to be done. Changes that relate to permissions cannot be taken lightly.

The recursive option was left on the screen as it was planned to be done but it looked to much of a nightmare for a first pass. Yes you are right, if you rezed your gun then applied the permissions to it, it would not be able to do anything to scripts etc inside the bullet without recursion, it would set the permissions on the bullet itself (if apply to objects was selected). The asset of the bullet would need to be retrieved and its inventory opened etc by the recursive process.

I agree it needs major QA as it could cause upset if wrong, but as it does a very specific well defined "thing" it should make automated or unit tests of the area a lot easier that a wide code base effecting patch.

Regards M2

Fixes some issues in previous patch( would only work if prims contained a script, would fail on items that had one no mod script even if the rest is your stuff, could crash the viewer if prims had no inventory)

Added the ability to set parent prims (eg selected prims) permissions at same time (optional, default =ON)

I can't add recuse, it looks difficult and infact i think that its not possible to get a prims inventory unless the simulator has that asset in context. As the resursive items are only assets in inventory this is therefor not currently possible without a simulator change too or some other major fiddling. Please tell me if i have this but wrong.

• It would be nice to be able to check / uncheck all the types in one go.

• I'd love to be able to set "Share with group" and (to a lesser extent) "Allow anyone to copy", too. :-D

• Setting permissions always fails for no-mod items, even for operations that are allowed, such as changing nomod|copy|trans to nomod|nocopy|trans.

• Trying to enable copy on no-copy items gives a false success message. (I.e. it says "[OK]", even though the item did not become copyable.)

• It should not be possible to disable all 3 perms. Right now, that is possible: all checkboxes become unchecked, Debug Permissions shows next owner having no perms, and the state persists even after transferring to another avatar (and back). The item behaves as transfer-only, so this is not a security issue, just a matter of potential confusion for users.

• The order for the permissions checkboxes should be Modify, Copy, Resell/Give Away, and ideally they should be layed out horizontally. This is for consistency with other parts of the UI.

• "Trans" should be "Resell/Give Away", also for consistency.

• "Textures" should read "Textures & Snapshots". (Alternatively, add a separate checkbox for snapshots, but I don't think that's needed.)

I'm going to work on a mock-up for the floater layout, as there's a lot of needless empty space. Right now, I'm picturing the 3 permissions boxes in ar ow at the top left, the types beneath that, Apply and Cancel buttons below that, and move the feedback text display to the right side of the floater.

If you do the floater mock up please attached it here, i can implemented the back end for any extra buttons, unless a Linden grabs it first but UI design and layout is not my strong point. I think all the points raised by yourself and Erica are valid for a cleaner UI. The unsetting of all 3 perms is protected server side so this can't be done but in every other peice of code the UI is protected against this so it needs adding here to.

The setting permission failing (#3) is caused my bad logic as i apply a test to see if it is allowed and use that to display the [OK]/ [FAILED] looks like i need to update the logic there too.

I think the other changes are all pretty much UI centric and i don't believe adding share with group and allow anyone to copy would be difficult.

M2

The 2nd issue is when working as a group having to remember to set the permissions (even via this feature) will still be a right PITA, imagine a private island where a team is building, this issue does not solve their problems but VWR-8049 does and would allow them all to work together with out remembering to re permission everything. Or a builder who always wants to create full perm obejcts, again keeping this and 8049 separate allows them to just specify there preferred defaults for building which out a clumsy 2nd step.

Thats why i think that VWR-5082 (this) and VWR-8049 are both very useful, complementary but independent features.

M2

Also VWR-8049 intends to address "allow anyone to copy" and "share with group" (but VWR-5082 could do that too in the future, so this is not a critical difference).

Finally, Michelle mentioned a number of use cases for VWR-8049. There is also one community for which VWR-8049 would be vital: the Open Source community. Having proprietary model as the default model for creation in Second Life is really something that is shocking to them, both on the point of view of the principle, and from a practical everyday point of view too.

However, there are things we could cooperate on : a set of default settings for example. In VWR-5082 they would be used in a "use default" button, used to return to the default settings, In VWR-8049 these default settings could be used upon creation or upload of new items. I don't see good reasons while we should use separate default settings for both features. But I might be wrong.

Another point where we could cooperate on is also the location of both features in the GUI. We could have adjacent menu entries in the "Tools" menu, for example.

#1 Bulk_Permissions_Mockup.png

The 3 permissions are laid out horizontally in the same order they appear elsewhere in the UI. Made a checkbox for the objects themselves, and an "overall" checkbox for all the content types. Enabling this checkbox would enable the child checkboxes; likewise for disabling. You can edit the child checkboxes individually, in which case the overall checkbox changes to the "mixed" state (not sure the technical term) to indicate that not all the child checkboxes have the same state. (The mixed state is the same one you see when you select multiple objects inworld with different permissions. I can try to clarify this more if this explanation is insufficient.)

I also decided to get rid of the results text box completely. Instead of having it built into the floater (which makes the floater much larger), I'd recommend a separate window come up with the results, as we see with script resets etc.

#2 Bulk_Permissions_Wide_Mockup.png

Same as #1, but with the built-in results text box, for comparison.

#3 Bulk_Permissions_Alt_Mockup.png

This represents how I'd actually like to apply the permissions. The current design doesn't allow operations like "Add modify, but leave copy and transfer as they are", which is something I would find very useful. So, this new design changes the checkboxes to 3 rows of radio buttons. The radio button labels should be self-explanatory.

I might try a mock-up with combo boxes instead of radio buttons; that would save some space, and maybe be more appealing.

To those who don't want to wait, CoolViewer at http://my.opera.com/boylane/blog/ has already implemented this feature. it's not as complete as the version pictured above, but it does work nicely and has saved me hours of frustrating, tedious work.

In linden/indra/newview/llfloaterbulkpermission.cpp, one can read:
LLCheckBoxCtrl* xfer = static_cast<LLFloaterPerms *>(data)->getChild<LLCheckBoxCtrl>("next owner transfer");

I think it should be:
LLCheckBoxCtrl* xfer = static_cast<LLFloaterBulkPermissions *>(data)->getChild<LLCheckBoxCtrl>("next owner transfer");

because I don't see the relation to LLFloaterPerms which is a completly different class than LLFloaterBulkPermissions.

Sorry in advance if I missed some point.

Everything seems to work quite smoothly. I only have a few minor aesthetic suggestions.

1. I initially had a hard time finding out how to access this new feature. I was looking under the Tools menu where the initial feature request suggested this should go, but it wasn't there. A "Permissions" button in the Contents tab was not the first (or second) thing I looked for. It's also a little confusing that this is the only operation that can be performed in the contents window when you have more than one object selected; I'm not used to being able to do anything there when I have multiple objects selected.

2. Is it possible to scroll the status text pane down as new lines are added? Otherwise it may not be clear that the operation is still in progress.

3. Clicking "close" while the operation is in progress seems to halt it midway. This could make sense, but it might be a good idea to either prevent the user from closing the dialog while the operation is in progress, or (preferably) warn them that continuing to close the window will abort the process.

Again, thank you SO MUCH for all of your work on this. This is an incredibly useful feature that has been a long time coming.

A number of months back a friend and I finished a big project. It took us A WEEK of mind-numbing and painful labor to set the permissions on everything. (They had been fullperm so we could give the items back and forth as we worked on them.) I had the foresight to restrict as much content to the root prim of the objects as possible, but it was still a long and painful process.

This tool will make many people's lives so much easier. Good tools allow better work to get done. Thank you so much for putting this in. Thank you Michelle, thank you Coco!

Jopsy Pendragon suggested to extend it so one could recursively change permissions in his/her user inventory. Currently it applies only to inworld objects as far as I know.

Citing Jopsy:

[it would be good to have] "The ability to (recursively) Change Permissions on all contents of selected FOLDERS in our inventory. (without having to step through each and every single item as we do now, even when selected as a group). (Yes it may allow someone to spam the inventory database with tens of thousands of updates. Limit it to 999 items and put a delay on it if necessary.)"