Permissions don't necessarily inherit. For instance, an estate manager cannot change the parcel description or set a parcel to show in search in SL. There is some sovereignity in he parcel owner role. Permissions are indeed separate and a non-inheriting model allows some useful combinations that an inheritance based model does not.
Melanie On 13/04/2012 15:48, Fleep Tuque wrote: > I'm trying to think of a use case when I wanted a PARCEL_OWNER to have > privileges that the ESTATE_MANAGER did/should not have and can't think of > one off the top of my head. In every scenario I can think of where I > assigned an Estate Manager through the Estate tools rather than using group > permissions, it was because I expected them to have MORE permissions than > the parcel owners and was setting that explicitly. > > Having said that, I do agree with Melanie that I would not expect a > permission change on PARCEL_OWNER to affect the permissions for > ESTATE_MANAGER. Generally I think of permissions inheriting "down" the > hierarchy, not "up", and I'm not sure the average grid owner would expect > that kind of behavior. > > - Chris/Fleep > > Chris M. Collins (SL/OS: Fleep Tuque) > Center for Simulations & Virtual Environments Research (UCSIM) > UCIT Instructional & Research Computing > University of Cincinnati > 406A Zimmer Hall > 315 College Drive > PO BOX 210088 > Cincinnati, OH 45221-0088 > [email protected] > (513) 556-3018 > > http://ucsim.uc.edu > > On Fri, Apr 13, 2012 at 9:02 AM, Melanie <[email protected]> wrote: > >> Not true. >> >> Even in SL estate owners/managers don't have some parcel rights. If >> I specify parcel owner, i expect parcel owner. Maybe a way needs to >> be found to combine multiple strings, e.g. >> ESTATE_MANAGER,PARCEL_OWNER. That would be acceptable. Changing the >> current behavior that people already depend on to relax security is >> not acceptable. It may mean that someone suddenly can do something >> they could not do before and the owners may not be aware of this, >> causing issues. >> >> Also, in case of a group owned parcel, group permissions govern what >> people in the group can do. Group members are by no means owners, >> often parcels are deeded only for access control but normal members >> have no rights whatsoever. Giving them potentially dangerous >> functions is not an option. >> >> On group owned parcels, those functions can be allowed either to >> group owners only (the group invite functions already do this check) >> or to deeded prims only. Allowing them for every member of the group >> is really bad. You don't really want to have your roleplay's members >> osTeleportAgent the opponents out of the fight! >> >> Again, relaxing existing constraints is not an option, but as you >> can see above, ways can be found to define combinations of >> permissions to allow more flexibility. >> >> Melanie >> >> On 13/04/2012 14:42, Oren Hurvitz wrote: >> > The decision whether to allow the parcel owner to call a function or not >> is >> > set by whoever setup OpenSim.ini: they can choose to allow PARCEL_OWNER, >> or >> > only ESTATE_OWNER. If they decided to allow the PARCEL_OWNER then we >> should >> > also allow the estate manager/owner to call that function. In addition, >> in >> > the case of a group-owned parcel, all members of the group are owners. >> > >> > So this change doesn't allow more permissions: it would only correct the >> > implementation of the existing permissions system, when PARCEL_OWNER has >> > been specified. >> > >> > -- >> > View this message in context: >> http://opensim-dev.2196679.n2.nabble.com/Remove-check-for-IsGod-in-some-OSSL-functions-tp7462127p7462567.html >> > Sent from the opensim-dev mailing list archive at Nabble.com. >> > _______________________________________________ >> > Opensim-dev mailing list >> > [email protected] >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> > >> > >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
