Sure, I can give exhaustive detail. It's rather deployment-specific,
though.
First, there are 4 different groups that need different sets of
permissions: admin1, admin2, staff, and development. Plus the 'anonymous'
user, of course. So 5 different combinations of permissions.
Permissions are created on install per resource type, in the following
groups: create, edit, view, fullreport. The first three are
straightforward, and if a user doesn't have fullreport permissions, they
only see a filtered version of a given resource report. Also, there is a
single permission for access to the RDM.
Each of the 5 groups has a unique set of these permissions. At least, I
have set it up for that to be the case. In reality, there is a much smaller
variation of permissions between groups and shortcuts could definitely have
been taken to make it less granular. But, now a member of a certain group
could be given one more specific permission from the django admin and their
group membership (and all of the group definitions themselves) remains
unchanged.
Creating these permissions is straight forward, but implementing was tricky
because they need to be available in a few different environments:
- context processor variables to be used in the templates (show/hide
things like the rdm button, etc.)
- in the views (many of which I had to migrate to my app) the request
object is referenced and a dictionary is made from all of a user's
permissions (*not* their group membership)
- I used permissions decorators for certain functions, like rdm()
- In some functions I used the permissions that I gained from the
request.user
- This is where I did all of the search result and map layer
filtering, by passing allowed resource types to the
elasticsearch query in
the doc_type argument.
- defined a variable in base.htm (based on the context processor) to be
used in all of the js files (for creating map layers, show/hide edit button
in the search results based on resource type, etc.)
I have yet to implement the specific filtering of information resources
based on a single attribute value. Now that I know how to filter ES hits,
I don't think this will be too awful hard, but I haven't tried it yet.
I would put specific code links here, but I may yet need to change some of
this stuff. You can track it all down in the repo
<https://github.com/mradamcox/afrh>though.
Adam
On Thu, Apr 28, 2016 at 12:05 PM, Alexei Peters <[email protected]> wrote:
> Adam,
> It sounds like you're doing exactly as I'd recommend. The setup.py file
> is there for exactly that reason.
> You mentioned working on a "different persmmisions system". Can you give
> any more detail? We're working on the permssions systems for v4 at the
> moment.
> -Alexei
>
>
> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>
> On Thu, Apr 28, 2016 at 10:33 AM, Adam Cox <[email protected]> wrote:
>
>> Making a package on top. I'm doing all of my development independent of
>> the arches and arches_hip packages that are in the virtual environment.
>> Lots of reasons for this, but the most obvious one is that I have a
>> virtualenv on my laptop and a separate one on the production server, and I
>> don't want to have to make changes to both of them.
>>
>> Because the node-level permission creation is built directly into the
>> resource graph loading function, I ended up just adding a function to my
>> setup.py file that finds all existing permissions and groups that have
>> already been created in installation process and deletes them. Then I have
>> another function that builds my own permissions from scratch.
>>
>> Adam
>>
>> On Thu, Apr 28, 2016 at 11:23 AM, Alexei Peters <[email protected]>
>> wrote:
>>
>>> Hi Adam,
>>> Are you making a package on top of HIP or modifying HIP directly?
>>> -Alexei
>>>
>>>
>>> Director of Web Development - Farallon Geographics, Inc. - 971.227.3173
>>>
>>> On Wed, Apr 6, 2016 at 12:25 PM, Adam Cox <[email protected]> wrote:
>>>
>>>> Hello all, I'm working on creating a different permission system than
>>>> is included in Arches-HIP, and I know how to create permissions, groups,
>>>> and users with new functions in my own setup.py, however, I'm not sure how
>>>> to stop Arches from making the default 'edit' and 'read' groups, and
>>>> creating all of the the node level permissions, without tinkering with the
>>>> virtual environment.
>>>>
>>>> An alternative approach would be to force the deletion of those two
>>>> groups and all of the existing permissions during the install process prior
>>>> to creating my own, but I'm not sure how to do that either.
>>>>
>>>> Any help is appreciated!
>>>> Adam
>>>>
>>>> --
>>>> -- To post, send email to [email protected]. To
>>>> unsubscribe, send email to [email protected].
>>>> For more information, visit
>>>> https://groups.google.com/d/forum/archesproject?hl=en
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Arches Project" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>
>
--
-- To post, send email to [email protected]. To unsubscribe, send
email to [email protected]. For more information,
visit https://groups.google.com/d/forum/archesproject?hl=en
---
You received this message because you are subscribed to the Google Groups
"Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
