How to make private contents

[Tetsuya Morimoto]

Hi,

I want to control private contents for each users. For example,
there're user1 and user2. The user1 made content1, then the content1
is viewed by user1 only. Also the user2 made content2, then content2
is viewed by user2 only.

I found a document about kotti security. Should I implement an
appropriate kotti.principals_factory? Or can I use some
repoze.workflow features?
http://kotti.readthedocs.org/en/latest/developer-manual.html#develop-security

thanks,
Tetsuya

[Christian Ledermann]

On Wed, Aug 15, 2012 at 11:08 AM, Tetsuya Morimoto
<tetsuya....@gmail.com> wrote:
> Hi,
>
> I want to control private contents for each users. For example,
> there're user1 and user2. The user1 made content1, then the content1
> is viewed by user1 only. Also the user2 made content2, then content2
> is viewed by user2 only.

yes this is how it works

> I found a document about kotti security. Should I implement an
> appropriate kotti.principals_factory? Or can I use some
> repoze.workflow features?
> http://kotti.readthedocs.org/en/latest/developer-manual.html#develop-security

I don't understand your question here. what are you asking?

> thanks,
> Tetsuya
>
> --
>
>



--
Best Regards,

Christian Ledermann

Nairobi - Kenya
Mobile : +254 702978914

<*)))>{

If you save the living environment, the biodiversity that we have left,
you will also automatically save the physical environment, too. But If
you only save the physical environment, you will ultimately lose both.

1) Don’t drive species to extinction

2) Don’t destroy a habitat that species rely on.

3) Don’t change the climate in ways that will result in the above.

}<(((*>

[Tetsuya Morimoto]

Thank you for quick response!

> I don't understand your question here. what are you asking?

You mean that Kotti handles the private content for each users by
default, right?
I haven't yet understood how to configure/implement to do that.
Could you show me about sample code or detailed procedure?

thanks,
Tetsuya

> --
>
>

[Christian Ledermann]

On Wed, Aug 15, 2012 at 11:56 AM, Tetsuya Morimoto
<tetsuya....@gmail.com> wrote:
> Thank you for quick response!
>
>> I don't understand your question here. what are you asking?
> You mean that Kotti handles the private content for each users by
> default, right?

yes. you have to test this with two 'normal' users, the admin can see eveything.

> I haven't yet understood how to configure/implement to do that.
> Could you show me about sample code or detailed procedure?

this is how it works by default. Do you want to implement new custom types
that have this behavior?


Note you need the newest version of kotti with workflow integration

[Tetsuya Morimoto]

I made two users (user1 and user2) with Viewer and Editor permission.
The user1 made "user1-document", and then user2 can view and edit the
content. It doesn't work for me. I used Kotti-0.7dev8 (github: master
e620df0f75), latest in this time.

> Do you want to implement new custom types that have this behavior?

Maybe, yes. But before doing so, I have to learn current feature since
it might be enough for me.

thanks,
Tetsuya

On Wed, Aug 15, 2012 at 6:02 PM, Christian Ledermann

> --
>
>

[Daniel Nouri]

On 08/15/2012 11:34 AM, Tetsuya Morimoto wrote:
> I made two users (user1 and user2) with Viewer and Editor permission.
> The user1 made "user1-document", and then user2 can view and edit the
> content. It doesn't work for me. I used Kotti-0.7dev8 (github: master
> e620df0f75), latest in this time.

It's because users with the editor role can view and edit private
items in the default workflow. From workflow.zcml:

<state name="private" callback="kotti.workflow.workflow_callback">
...
<key name="role:editor" value="view add edit state_change" />
...
</state>

I _think_ it makes sense to give the editor that, but not 100% sure.


Daniel

>>>> 1) Don�t drive species to extinction
>>>>
>>>> 2) Don�t destroy a habitat that species rely on.
>>>>
>>>> 3) Don�t change the climate in ways that will result in the above.

>>>>
>>>> }<(((*>
>>>>
>>>> --
>>>>
>>>>
>>>
>>> --
>>>
>>>
>>
>>
>>
>> --
>> Best Regards,
>>
>> Christian Ledermann
>>
>> Nairobi - Kenya
>> Mobile : +254 702978914
>>
>> <*)))>{
>>
>> If you save the living environment, the biodiversity that we have left,
>> you will also automatically save the physical environment, too. But If
>> you only save the physical environment, you will ultimately lose both.
>>

>> 1) Don�t drive species to extinction
>>
>> 2) Don�t destroy a habitat that species rely on.
>>
>> 3) Don�t change the climate in ways that will result in the above.
>>
>> }<(((*>
>>
>> --
>>
>>
>

[Christian Ledermann]

On Wed, Aug 15, 2012 at 12:58 PM, Daniel Nouri <daniel...@gmail.com> wrote:
> On 08/15/2012 11:34 AM, Tetsuya Morimoto wrote:
>>
>> I made two users (user1 and user2) with Viewer and Editor permission.
>> The user1 made "user1-document", and then user2 can view and edit the
>> content. It doesn't work for me. I used Kotti-0.7dev8 (github: master
>> e620df0f75), latest in this time.
>
>
> It's because users with the editor role can view and edit private
> items in the default workflow. From workflow.zcml:
>
> <state name="private" callback="kotti.workflow.workflow_callback">
> ...
> <key name="role:editor" value="view add edit state_change" />
> ...
> </state>
>
> I _think_ it makes sense to give the editor that, but not 100% sure.

+1

but as it is currently the case you need the editor role to add content.

would it make sense to you to add a 'contributor' (or so) role who
can add content and only edit his own contents?

>>>>> 1) Don’t drive species to extinction
>>>>>
>>>>> 2) Don’t destroy a habitat that species rely on.
>>>>>
>>>>> 3) Don’t change the climate in ways that will result in the above.

>>>>>
>>>>> }<(((*>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>>
>>> Christian Ledermann
>>>
>>> Nairobi - Kenya
>>> Mobile : +254 702978914
>>>
>>> <*)))>{
>>>
>>> If you save the living environment, the biodiversity that we have left,
>>> you will also automatically save the physical environment, too. But If
>>> you only save the physical environment, you will ultimately lose both.
>>>

>>> 1) Don’t drive species to extinction
>>>
>>> 2) Don’t destroy a habitat that species rely on.
>>>
>>> 3) Don’t change the climate in ways that will result in the above.

>>>
>>> }<(((*>
>>>
>>> --
>>>
>>>
>>
>
> --
>
>



--
Best Regards,

Christian Ledermann

Nairobi - Kenya
Mobile : +254 702978914

<*)))>{

If you save the living environment, the biodiversity that we have left,
you will also automatically save the physical environment, too. But If
you only save the physical environment, you will ultimately lose both.

1) Don’t drive species to extinction

2) Don’t destroy a habitat that species rely on.

3) Don’t change the climate in ways that will result in the above.

}<(((*>

[Daniel Nouri]

On 08/15/2012 01:11 PM, Christian Ledermann wrote:
> On Wed, Aug 15, 2012 at 12:58 PM, Daniel Nouri <daniel...@gmail.com> wrote:
>> On 08/15/2012 11:34 AM, Tetsuya Morimoto wrote:
>>>
>>> I made two users (user1 and user2) with Viewer and Editor permission.
>>> The user1 made "user1-document", and then user2 can view and edit the
>>> content. It doesn't work for me. I used Kotti-0.7dev8 (github: master
>>> e620df0f75), latest in this time.
>>
>>
>> It's because users with the editor role can view and edit private
>> items in the default workflow. From workflow.zcml:
>>
>> <state name="private" callback="kotti.workflow.workflow_callback">
>> ...
>> <key name="role:editor" value="view add edit state_change" />
>> ...
>> </state>
>>
>> I _think_ it makes sense to give the editor that, but not 100% sure.
>
> +1
>
> but as it is currently the case you need the editor role to add content.
>
> would it make sense to you to add a 'contributor' (or so) role who
> can add content and only edit his own contents?

Fine with me. Would this follow Tetsuya's expectations?

We can add this extra role in 0.7.1.



Daniel

[Tetsuya Morimoto]

Thank you for considering! I really want such new role. I'm looking
forward to releasing.

thanks,
Tetsuya

[Daniel Nouri]

If someone wants to help out with this, there's a few places in
security.py where we'd need to add that 'role:contributor', and then in
workflow.zcml.


Daniel

[Tetsuya Morimoto]

> If someone wants to help out with this, there's a few places in security.py
> where we'd need to add that 'role:contributor', and then in workflow.zcml.

I'm learning Kotti security feature, so I try to help out.

> --
>
>

[Christian Ledermann]

On Thu, Aug 16, 2012 at 5:52 AM, Tetsuya Morimoto
<tetsuya....@gmail.com> wrote:
>> If someone wants to help out with this, there's a few places in security.py

as far as i can see add

in security.py to ROLES:

u'role:contributor': Principal(u'role:contributor', title=_(u'Contributor')),

and in SITE_ACL:

['Allow', 'role:contributor', ['add']],


As the creator of an item gets the role 'Owner' (does he? scanning the code
I did not find it) the workflow should be OK as is

[Daniel Nouri]

On 08/16/2012 08:18 AM, Christian Ledermann wrote:
> On Thu, Aug 16, 2012 at 5:52 AM, Tetsuya Morimoto
> <tetsuya....@gmail.com> wrote:
>>> If someone wants to help out with this, there's a few places in security.py
>
> as far as i can see add
>
> in security.py to ROLES:
>
> u'role:contributor': Principal(u'role:contributor', title=_(u'Contributor')),
>
> and in SITE_ACL:
>
> ['Allow', 'role:contributor', ['add']],
>
>
> As the creator of an item gets the role 'Owner' (does he? scanning the code
> I did not find it) the workflow should be OK as is

Yes, he does. The owner is set in 'kotti.events.set_owner' (if it
hasn't been set before).


Daniel

[Tetsuya Morimoto]

Hi,

I'm debugging now. I encountered a little complicated situation. I
added "role:contributor" and modified
security.py/populate.py/workflow.zcml as follows.

kotti/security.py

SITE_ACL = [
['Allow', 'system.Everyone', ['view']],
['Allow', 'role:viewer', ['view']],
['Allow', 'role:editor', ['view', 'add', 'edit', 'state_change']],
['Allow', 'role:owner', ['view', 'add', 'edit', 'manage',
'state_change']],
['Allow', 'role:contributor', ['view', 'add']],
]

kotti/populate.py (for debugging)

def populate():
if DBSession.query(Node).count() == 0:
root = Document(**_ROOT_ATTRS)
root.__acl__ = SITE_ACL
print 'SITE_ACL:'
print root.__acl__
DBSession.add(root)
root['about'] = Document(**_ABOUT_ATTRS)

wf = get_workflow(root)
if wf is not None:
DBSession.flush() # Initializes workflow
print 'after DBSession.flush():'
print root.__acl__
wf.transition_to_state(root, None, u'public')
print 'after wf.transition_to_state(root, None,
"public"):'
print root.__acl__

kotti/workflow.zcml

<state name="public" callback="kotti.workflow.workflow_callback">
.. (snip) ..
<key name="role:contributor" value="view" />
</state>

I got some debug output as follows when a root content was populated.

SITE_ACL:
[['Allow', 'system.Everyone', ['view']],
['Allow', 'role:viewer', ['view']],
['Allow', 'role:editor', ['view', 'add', 'edit', 'state_change']],
['Allow', 'role:owner', ['view', 'add', 'edit', 'manage', 'state_change']],
['Allow', 'role:contributor', ['view', 'add']]]

after DBSession.flush():
[('Allow', 'role:owner', u'view'),
('Allow', 'role:owner', u'add'),
('Allow', 'role:owner', u'edit'),
('Allow', 'role:owner', u'manage'),
('Allow', 'role:owner', u'state_change'),
('Allow', 'role:viewer', u'view'),
('Allow', 'role:editor', u'view'),
('Allow', 'role:editor', u'add'),
('Allow', 'role:editor', u'edit'),
('Allow', 'role:editor', u'state_change'),
('Deny', 'system.Everyone', <pyramid.security.AllPermissionsList
object at 0x23998d0>)]

after wf.transition_to_state(root, None, "public"):
[('Allow', 'role:contributor', u'view'),
('Allow', 'role:owner', u'view'),
('Allow', 'role:owner', u'add'),
('Allow', 'role:owner', u'edit'),
('Allow', 'role:owner', u'manage'),
('Allow', 'role:owner', u'state_change'),
('Allow', 'role:viewer', u'view'),
('Allow', 'role:editor', u'view'),
('Allow', 'role:editor', u'add'),
('Allow', 'role:editor', u'edit'),
('Allow', 'role:editor', u'state_change'),
('Allow', 'system.Everyone', u'view'),
('Deny', 'system.Everyone', <pyramid.security.AllPermissionsList
object at 0x23998d0>)]


After "wf.transition_to_state(root, None, u'public')" is executed,
"('Allow', 'role:contributor', u'view')" attribute is added by
referring to workflow.zcml. To be able to add a document to root
content by a user with "role:contributor", it need an "add"
permission. However, I don't want to set "add" permission for
"role:contributor" in workflow.zcml, because another user with
"role:contributor" can add any private contents.

I don't know why "role:contributor" attribute is not added to
root.__acl__ when "root.__acl__ = SITE_ACL" is set and
"DBSession.flush()" is executed. Is my thinking something wrong?

thanks,
Tetsuya

> --
>
>

[Daniel Nouri]

I don't understand why you wouldn't want to give "role:contributor"
the "add" permission.

> I don't know why "role:contributor" attribute is not added to
> root.__acl__ when "root.__acl__ = SITE_ACL" is set and
> "DBSession.flush()" is executed. Is my thinking something wrong?

The flush will initialize the root's __acl__ with what's defined in
the workflow. So if you have a workflow defined, the SITE_ACL will
actually be overwritten by what's in workflow.zcml.

Cheers,
Daniel

[Tetsuya Morimoto]

> The flush will initialize the root's __acl__ with what's defined in
> the workflow. So if you have a workflow defined, the SITE_ACL will
> actually be overwritten by what's in workflow.zcml.

I understood that overwriting SITE_ACL by workflow.zcml is specification.

Now, I modified workflow.zcml as follows. The root.__acl__ has
('Allow', 'role:contributor', u'view') and ('Allow',
'role:contributor', u'add').

workflow.zcml:

<state name="private" callback="kotti.workflow.workflow_callback">
.. (snip) ..
<key name="role:contributor" value="" />
</state>

<state name="public" callback="kotti.workflow.workflow_callback">
.. (snip) ..

<key name="role:contributor" value="view add" />
</state>

Imagine there're user1 and user2 with with "role:contributor". In this
case, user2 cannot view user1's document if the document content is
private. Also, user1 cannot view user2's one. If user1 change its
state public, user2 can view and add a document into user1's document.
Is this appropriate behavior?

thanks,
Tetsuya

> --
>
>

[Andreas Kaiser]

On 16.08.2012, at 12:38, Tetsuya Morimoto <tetsuya....@gmail.com> wrote:

>> The flush will initialize the root's __acl__ with what's defined in
>> the workflow. So if you have a workflow defined, the SITE_ACL will
>> actually be overwritten by what's in workflow.zcml.
> I understood that overwriting SITE_ACL by workflow.zcml is specification.
>
> Now, I modified workflow.zcml as follows. The root.__acl__ has
> ('Allow', 'role:contributor', u'view') and ('Allow',
> 'role:contributor', u'add').
>
> workflow.zcml:
>
> <state name="private" callback="kotti.workflow.workflow_callback">
> .. (snip) ..
> <key name="role:contributor" value="" />
> </state>
>
> <state name="public" callback="kotti.workflow.workflow_callback">
> .. (snip) ..
> <key name="role:contributor" value="view add" />
> </state>
>
> Imagine there're user1 and user2 with with "role:contributor". In this
> case, user2 cannot view user1's document if the document content is
> private. Also, user1 cannot view user2's one. If user1 change its
> state public, user2 can view and add a document into user1's document.
> Is this appropriate behavior?

Depends on what you want to achieve.

If you really want these users to be able to add arbitrary children to all public nodes, then yes.

A more common use case might be that you want your users to have some kind of "home folder". In that case you wouldn't assign roles to your users globally at all. Instead you'd assign them locally on their respective "home folder" (or just make them the owner of that content node) and wouldn't need to change the default workflow at all.


HTH,

Andreas

[Tetsuya Morimoto]

Thank you for your comment. It's truth. But, I wanted to confirm
"role:contribute" attribute and its behavior by default. Because,
Nouri said "role:contributor" will be added in Kotti 0.7.1.
Additionally, I learned we can set own "kotti.populators" and/or
"kotti.use_workflow" configuration even if my requirements is
different from Kotti's default behavior.

> A more common use case might be that you want your users to have some kind of "home folder". In that case you wouldn't assign roles to your users globally at all. Instead you'd assign them locally on their respective "home folder" (or just make them the owner of that content node) and wouldn't need to change the default workflow at all.

I see! This way is also good for me.

thanks,
Tetsuya

> --
>
>

[Daniel Nouri]

OK, in that case I won't add 'role:contributor' to the default
worfklow for now. Unless we decide it's a general enough use case to
be there. (Third party apps can always add their own roles.)


Daniel

[Tetsuya Morimoto]

Yes, I agree with you. I learned a little about Kotti's security and
workflow to achieve my needs. Thank you for giving me useful advices!

thanks,
Tetsuya