Re: sharing scenario - feedback needed
Chad Burt
control sharing at a granular level through group permissions. In the
scenario where we want to prevent users from sharing tribal use areas
with the entire RSG but still allow sharing with a certain user group,
we would be opening up the possibility of mistakes. If there is an
onerous performance penalty we might want to reexamine, but I think it
clearly *should* behave like this.
-Chad
On Thu, Jan 27, 2011 at 10:59 AM, Matt Perry <perr...@gmail.com> wrote:
> Damn it - right after the call I realized that with the 'everything is
> potentially shareable; group permissions determines shareability"
> approach that we've just passed the conceptual problem on...
>
> Lets say group1 'can_share_folders' but does not have
> 'can_share_renewableenergysites' ... is RenewableEnergySite1 shared
> implicitly even though the group permissions don't permit it?
>
> - matt
>
> On Thu, Jan 27, 2011 at 9:49 AM, Chad Burt <underbl...@gmail.com> wrote:
>> That's a tough one. My immediate reaction was C since that seems
>> pretty intuitive from the api side. It's what you'd expect. One the
>> other hand... we have to think about what being able to turn sharing
>> on/off at the model level rather than globally gives us the
>> flexibility to do. I think the overwhelmingly common case would be
>> that sharing is either on or off for everything. The only other case I
>> could foresee is if we wanted to say "You're only allowed to share
>> complete proposals, not individual energy sites". I'm not sure how
>> common that would be though. We should discuss during the dev call.
>> -Chad
>>
>> On Thu, Jan 27, 2011 at 8:18 AM, Matt Perry <perr...@gmail.com> wrote:
>>> Maybe something for the dev call this morning but I've stumbled on an
>>> interesting potential scenario with sharing:
>>>
>>> Lets say we've got 2 types of collections
>>> - Folders (can only contain Proposals)
>>> - Proposals (can contain MPAs and RenewableEnergySites)
>>>
>>> And two types of spatial features:
>>> - MPA
>>> - RenewableEnergySites
>>>
>>> And for some reason we don't want RenewableEnergySites to be shared
>>> (ie class Options: share = False)
>>>
>>> Someone could potentially create a structure like:
>>>
>>> Folder1
>>> |-- Proposal1
>>> |-- MPA1
>>> |-- RenewableEnergySite1
>>>
>>> Now let's say they share Folder1. What happens to RenewableEnergySite1? Is it:
>>>
>>> a) Automatically shareable globally by virtue of it being a potential
>>> child of a shareable collection
>>> b) Shareable only in the context of it's collection being shared
>>> c) Not shareable at all (ie honor the explicit Options of the model)
>>>
>>> I realize this scenario is unlikely to come up in practice if we just
>>> use the rule of thumb that if a feature is going to be a valid child
>>> of a shareable container, just make the feature itself share=True. And
>>> perhaps that's enough? But the possibility of this happening (by
>>> accident or by design) is still there and it might be worthwhile to
>>> think about how we handle it.
>>>
>>> Implementation wise, c) is how things currently work. a) would not be
>>> too difficult; we'd just need to check for shareable potential_parents
>>> and register it as shareable content. b) might get tricky.
>>> --
>>> ·´¯`·.¸. , . .·´¯`·.. ><((((º>`·.¸¸.·´¯`·.¸.·´¯`·...¸><((((º>
>>> "The best way to predict the future is to invent it." -- Alan Kay
>>> Matthew T. Perry
>>> http://www.perrygeo.net
>>> http://viedevelo.wordpress.com
>>>
>>
>>
>>
>> --
>> -Chad
>>
>
>
>
> --
> ·´¯`·.¸. , . .·´¯`·.. ><((((º>`·.¸¸.·´¯`·.¸.·´¯`·...¸><((((º>
> "The best way to predict the future is to invent it." -- Alan Kay
> Matthew T. Perry
> http://www.perrygeo.net
> http://viedevelo.wordpress.com
>
--
-Chad
Scott Fletcher
Does this intermediate folder simplify things from a developers perspective?
-Scott
--
You received this message because you are subscribed to the Google Groups "marinemap-dev" group.
To post to this group, send email to marine...@googlegroups.com.
To unsubscribe from this group, send email to marinemap-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/marinemap-dev?hl=en.
Chad Burt
differentiate public proposals from proposals shared through groups.
-Chad
--
-Chad
Scott Fletcher
I was given the impression we were implementing two distinct folder types, one for shapes and one for other folders.
Now it sounds like what's actually the case is that a user can create a folder which can be organized to contain other folders and/or shapes (and those folders can be nested, etc).
Is that right?
'Proposal' was just an example of a type of FeatureCollection that
could conceivably be implemented.
Folders, Array, Proposals, GroupsOfRelatedThings, whatever you want,
can be created using MM2 and they can contain other collections in a
nested fashion. Much of the refactor has to do with handling all the
potential nesting of collections as this requires recursive functions.
- matt
Chad Burt
FeatureCollection within a project and configured however needed. It's
pretty flexible on the lingcod side. I don't think we've made a
decision whether a Folder class would be built-in to lingcod. If it
was it wouldn't automatically be registered.
--
-Chad
Matt Perry
> Ah. Maybe I was thrown off by the description in the email we reviewed
> during the Gotomeeting in which Folders were said to contain Proposals and
> Proposals were said to contain shapes.
This was just an example of how a project might be arranged. The goal
is to have base classes for Features and FeatureCollections and the
project can define what features it needs, how those features behave,
how those features can be organized into collections, how those
collections can nest, etc.
> I was given the impression we were implementing two distinct folder types,
> one for shapes and one for other folders.
>
It's possible that we may need to implement something like this on
some project in the future .. but it is not enforced and entirely
configurable in the model Options.
> Now it sounds like what's actually the case is that a user can create a
> folder which can be organized to contain other folders and/or shapes (and
> those folders can be nested, etc).
>
> Is that right?
>
Yeah. The base design is (almost) infinitely flexible and allows
Features and FeatureCollections to be related in what ever way the
project requires. Of course that means that the base design needs to
account for and anticipate how to handle all those scenarios ..
.therein lies the complexity of this refactor!
Matt Perry
1) We decided to make Features/Collections globally 'shareable' and
rely on the group permissions to determine if a user can share a given
Feature/Collection. After reviewing the code, it wont be too difficult
(3-4 days) to refactor lingcod.sharing to support this. It already
does this to some extent - we just need to remove lots of code which
checks that feature type is registered with the sharing app (this will
no longer be necessary).
2) I'm still not satisfied with our resolution on recursive collection
behavior regarding sharing. Let me throw a few more wrenches into the
engine:
Lets say we have GroupA that has permission to share the following
Features/Collections amongst themselves:
- AOIs
- GenericCollection
GroupA does NOT have permission to share:
- CulturalAreas
- CollectionOfCulturalAreas
GenericCollections are configured to contain *anything*
CollectionsOfCulturalAreas are configured to contain only CulturalAreas.
Someone in Group A could create:
My GenericCollection
|-- My AOI
|-- My Other GenericCollection
|-- My CollectionOfCulturalAreas
|-- My CulturalArea
Now, as a member of Group A, they would have permission to share 'My
GenericCollection' to the group.
So the question is, can other members of Group A view 'My
CulturalArea' even though GroupA explicitly does not have permission
to share them? What I'm hearing from Chad is a NO - even though the
collection is shared, the unshareable objects within the collection
should be hidden or inaccessible. I tend to agree BUT....
Lets say that, to facilitate organization of
CollectionsOfCulturalAreas, they are re-configured to contain
GenericCollection (folders in a sense) in addition to CulturalAreas.
We could end up with something like this:
My GenericCollection
|-- An AOI
|-- My Other GenericCollection
|-- My CollectionOfCulturalAreas
|-- A GenericCollection of Related Stuff
|-- Another Cultural Area
|-- An AOI that was accidentally placed here
|-- My CulturalArea
Would Group A then have access to `An AOI that was accidentally placed
here`? It is an AOI within a GenericCollection (albeit a few levels
deep) so you could argue YES. But its organizing hierarchy would be
foobar since it was contained within unshareable collections. You
could imagine a deeply nested structure of mostly shareable elements
with a few non-shareable collections throw in - does everything below
them get ignored? if not, what do we do to represent the structure for
those orphaned shareable features?.
To be clear, I'm not saying this is a common use case or that this is
how a project *should* be configured but as long as we provide a
flexible framework that theoretically allows it, we need to come up
with ways to gracefully handle it. Even though placing that AOI in the
previous example would be the users error, at some point in the code
we need to make a binary YES/NO decision for whether a given user can
read a given feature.
Whew... confused yet? I am. I've come up with half a dozen other edge
cases but I'll spare you! I think if we answer the above questions, we
have a conceptual framework to proceed.
- matt
Chad Burt
be illustrative:
|-My Shapes
|- Folder "Features I've designed to totally screw over Bob's Plan"
|- Feature A *Shared*
|- Feature B
|- Feature C
I think in this case the user would want Feature A to be shared
without appearing to other users to be nested under the folder.
Similarly, I think in the case you described the AOI should just be
floating un-nested in the shared shapes list for that user.
-Chad
--
-Chad
Matt Perry
most part - if a feature is shared, the collection *above* it is
irrelevant. I'm interested in the currently indeterminate behavior of
the opposite case - what happens to features in the hierarchy that are
*beneath* a shared collection. IOW it doesn't address the issue of:
If the collection 'My Shapes' is shared, can other users see Feature B
implicitly? Does it depend on whether the group has permission
can_share_features? How would the granting/revoking the
can_share_folders permission change the answer?
- matt
Scott Fletcher
I guess I was thinking that our idea of sharing might be elevated to something as simple as 'can a user/group share shapes/collections', and if so, then 'who can they share with' (other members in their group, the public, etc) would be the other decisions an admin might make. This would completely forgo any admin-based decision making regarding what shapes (or what kind of shapes) are shareable and what shapes aren't (thus side-stepping the whole 'what to do about shared folders that contain both shareable and un-shareable content).
Is there a use case in which a user should be able to share one shape and not another?
Or are we just trying to 'help' prevent the user from getting into hot water when they share the wrong shape (making the mistake of trying to predict the user's intentions, rather than letting the user manage their own intentions responsibly)?
-Scott
Matt Perry
On Fri, Jan 28, 2011 at 5:01 PM, Scott Fletcher <sfle...@gmail.com> wrote:
> I guess I was thinking that our idea of sharing might be elevated to
> something as simple as 'can a user/group share shapes/collections', and if
> so, then 'who can they share with' (other members in their group, the
> public, etc) would be the other decisions an admin might make. This would
> completely forgo any admin-based decision making regarding what shapes (or
> what kind of shapes) are shareable and what shapes aren't (thus
> side-stepping the whole 'what to do about shared folders that contain both
> shareable and un-shareable content).
Very true. Making features and collections globally shareable within
groups would greatly simplify the scope of the problem. Basically
sharing would be a yes/no decision at the group level - anything you
create can be shared if your group has sharing turned on.
Maybe the focus should be defining which feature/collection types
groups are allowed to even *create*. It doesn't really make much
sense to allow someone to create it but not share it.
For sharing to the public and to administrators, those would just be a
special-case groups as defined in settings.
>
> Is there a use case in which a user should be able to share one shape and
> not another?
That's a good question. I'd say there are cases where we'd want to
only allow certain groups the ability to *create* certain types of
features (ie native american groups are the only ones allowed to make
NativeAmericanCulturalArea polygons.) But once we've allowed someone
to create a feature, what do we gain by preventing them from sharing
it?
> Or are we just trying to 'help' prevent the user from getting into hot water
> when they share the wrong shape (making the mistake of trying to predict the
> user's intentions, rather than letting the user manage their own intentions
> responsibly)?
>
I think the simple group sharing = on/off approach is great and really
simplifies things. If you can create it and your group has sharing
turned on, when would you ever want to prevent them from sharing it?
To play devils advocate: I could also see a tenuous case where a
certain group doesn't want information shared (even internally to the
group) yet they want to be able to create shapes and play around with
the analyses. They'd need that granular control over sharing.
It's a question of whether we want to support this uber-flexible
granular permissions approach (which has a rare use case?) OR a group
level sharing on/off (which would simplify the concept and
implementation). I vote for the later.
- matt
Chad Burt
reasonable approach since we don't have an immediate use case for more
granular control. Preventing users from accidentally sharing features
nested within a FeatureCollection might be better achieved through
clear notification in the user interface that all children of the
FeatureCollection will be shared.
Another benefit is that this would make it much easier to explain to
planners what their options are for configuring the tool. Sometimes
providing too much control means people see a need to use it where it
might just cause confusion. In that same spirit, I'm not sure we need
to control what features each group can create... at least not yet. It
seems like something that would be pretty simple to implement if there
is a clear project need.
-Chad
--
-Chad
Matt Perry
> Having sharing be a binary setting for each group seems like a
> reasonable approach since we don't have an immediate use case for more
> granular control.
Cool. While that does mean abandoning a lot of the sharing app, it
will make the CMS branch a whole lot easier to develop!
> Preventing users from accidentally sharing features
> nested within a FeatureCollection might be better achieved through
> clear notification in the user interface that all children of the
> FeatureCollection will be shared.
I'm not even sure that's necessary as it's probably the expected
behavior anyways. But I'll make the sharing notification an easily
configurable option.
>
> Another benefit is that this would make it much easier to explain to
> planners what their options are for configuring the tool. Sometimes
> providing too much control means people see a need to use it where it
> might just cause confusion.
Agreed. We had trouble discussing it amongst ourselves - I can't
imagine trying to explain the nuances of granular sharing control to a
non-technical stakeholder!!
> In that same spirit, I'm not sure we need
> to control what features each group can create... at least not yet. It
> seems like something that would be pretty simple to implement if there
> is a clear project need.
Cool - I'll hold off on that for now. Over the weekend, I came up with
a few problems in that approach anyhow.
So to summarize:
Any user can create any type of feature. If they belong to a group
that has sharing turned on, they can share all of their features. If
they organize their features into collections and share those
collections, all features in that hierarchy are implicitly shared.
Sounds good to me. Very straightforward and much less complicated than
the granular approach. I'll go over the code and make a re-estimate of
all the tasks given this change in scope - i expect it will speed
things up a bit.
Chad Burt
> Any user can create any type of feature. If they belong to a group
> that has sharing turned on, they can share all of their features. If
> they organize their features into collections and share those
> collections, all features in that hierarchy are implicitly shared.
Documentation will be a breeze!
-Chad