Edit permissions

#1

Because the mini gold game. I still see the following problem. We all talked about it in the past. and it did go moved a bit on the side track as. domain owners and trust.

Right now you can give someon edit permissions or no edit permissions. That’s all.

But this setup, does not fit in what peoiple want todo. and also good for drama.
Im pretty sure that people want to share domains or build togheter on one domain. It’s hugh you know !

But the current problem is that when you give some one edit permissions. he can edit EVERYTHING ! Also that owner could copy url’s and reuse it on other domain if it’s not ATP. See the drama around the next corner ! So we still fall back on soem ideas of Secondlife.

In this case it would be good if entities can only be editted by the owner. Now i think that’s problematic in high fidelity. I would not know that can be implemented. We have devs for that :slight_smile:

I suggest that other people with edit rigths cannot access your entities without permission from the owner.

It’s suggestion. But io think soem chat and othger idea’s would be nice. I still see it as a required functionality. ANd my experienes is based on other worlds too.

#2

Yeah… to me the current all-or-nothing edit permissions are not entirely practical…

Maybe for Entity-level permissions there could be a new “access” property – which isn’t perfect either, but might be able to hit several common cases with one blow:

// anybody is allowed to edit any property:
access: true 

// only these (logged-in) usernames can edit any property:
access: '@Richardus.Raymaker, @humbletim'

// anybody can edit any property -- *except* for those listed:
access: '%all, !position, !orientation, !name, !script'

// anybody can edit "physical" and "spatial" properties
// (which could match the editor's Entity Properties sections)
access: '%physical, %spatial'

For my own scenarios that would still be insufficient so what I am planning to do is have an AC Script operate as a Master Control Program (MCP) for the whole Domain – managing finer-grained access, editing permissions and centralized Entity scripts (ie: ran in AC space instead of N-way Client spaces).

Annonymous users are able to move things, ignoring perms
#3

Sounds intresting, thats available for everyone ? Need to admit i never done scripting for AC.
Except that i use many scropt at entity level. So we need a solution for that.

#4

Well AC scripting is part of built-in Domain Server / Assignment Client functionality – so in that sense yeah.

#5

Thanks, but i first plan to get my door working with the vive controller.
That;s already a challange, especially if the controller is not responding anymore in hifi. (reboot ?) And a log thats full with spam messages.

AC is different story.
Still curious if High Fidelity could implement soemthing on AC level that can protect entities and regulate edit permissions for all entities on domain.

#6

Do you happen to know if this is still something planned? I realize this is an old thread but thought I would ask here. As an educator looking to bring in large groups of students it’s not going to work at all in regards to editing if everyone can edit each others entities. It will be total chaos. The only other option we have is to force students to build alone inside their sandbox worlds and that defeats the social learning we are trying to promote. The ideal situation is one that only allows users to edit their own entities. I realize this may never be possible in highfi though. Is there a workaround? We looked at all the filters but they do not accomplish much for our uses. All we want to do is give each student their own zone in the SAME domain, and in that zone only that particular student is allowed to edit/delete etc. Of course the admin would be able to as well.

1 Like
#7

Our Studio has accomplished this. We are preparing to engage in an alpha-testing period in May.
cc: @AlphaVersionD, @Caitlyn

2 Likes
#8

Fantastic! If this giant hurdle can be overcome it will really open more doors to realistically bring in our students for our first pilot. We have been working with students in immersive settings for a very very long time and know that one of the most important things from an educator’s standpoint is being able to control what is happening within the environment. If this new generation is going to be the main user base, we want to start getting them in here but in the current incarnation it’s not realistic from a "management’ standpoint. Social learning brings so much value and we do see HF as a potential catalyst but right now…maybe not. This is because there is no logical and easy way for students to safely create, collaborate and build in a controlled way in the same domain. We have seen it happen over and over again in other platforms where kids will try to be sneaky or funny and walk up to someone’s build and change it, or edit it etc. It’s going to happen. The key here is limiting that and being able to log users and control it somewhat. Yes, it’s important for this new generation of kids to understand ethical decision making but that takes time and maturity. We want them to feel safe and for them to feel that all the effort they put into what they create will not go out the window with one click of a button. Of course they can do what they want in their own sandbox but that is not an option for our use case and gets back to the whole ‘walled garden’ issue with people working in isolation. High Fidelity is the most progressive, inventive, forward thinking VR platform out there. I see a bright future with it and appreciate the strong community and support here so I am hopeful progress will be made with the whole permission system. One side note, I hope HF does not underestimate the importance of the desktop user. That is how we will be bringing in 80% of our current student user base. Only a small percentage will have VR headsets. But, once they get in here and start to see what is possible I can guarantee you it will set off a firestorm. Over time, as hardware becomes more affordable, it will become standard to throw on the HMD. But initially, we will develop activities that can be done just fine on the desktop and then be ‘enhanced’ by experiencing it via the HMD. So in other words, for our students who don’t have an HMD, they can still participate. We are looking at this from a different perspective. A way to show them the way. Baby steps.

1 Like