[Erp5-dev] [Erp5-report] r19359 - /erp5/trunk/products/ERP5/bootstrap/erp5

Discussion:

[Erp5-dev] [Erp5-report] r19359 - /erp5/trunk/products/ERP5/bootstrap/erp5_core/SkinTemplateItem/porta...

Jérome Perrin

2008-02-29 18:51:37 UTC

Author: bartek
Date: Mon Feb 18 15:49:28 2008
New Revision: 19359
URL: http://svn.erp5.org?rev=19359&view=rev
get acquired membership too
erp5/trunk/products/ERP5/bootstrap/erp5_core/SkinTemplateItem/portal_skins/erp5_core/ERP5Type_getSecurityCategoryFromArrow.xml
for base_category in base_category_list:\n
- category_list.append({base_category: object.getCategoryMembershipList(base_category)})\n
+ category_list.append({base_category: object.getAcquiredCategoryMembershipList(base_category)})\n

Hello,

The problem with a security based on acquired categories is that you
won't be able to easily regenerate local roles when a category is
changed. When the category is set on the document, we usually add an
interaction workflow on set.* to update local roles. If the category is
acquired from another document, the interaction workflow must be on the
other document, and all documents acquiring values from the other must
be updated. Finding "all documents acquiring values from a document" is
not possible, they can only be guessed in an ad-hoc way.

For safety / consistency with existing API, we should keep the old
ERP5Type_getSecurityCategoryFromArrow behaviour and introduce a new
script using acquired categories,
"ERP5Type_getSecurityCategoryFromAcquiredArrow".

I did this in r19639, but this can still be discussed if you want.

J?rome

Jérome Perrin

2008-03-04 19:28:03 UTC

Permalink

Post by JÃ©rome Perrin

Hello,
The problem with a security based on acquired categories is that you
won't be able to easily regenerate local roles when a category is
changed. When the category is set on the document, we usually add an
interaction workflow on set.* to update local roles. If the category is
acquired from another document, the interaction workflow must be on the
other document, and all documents acquiring values from the other must
be updated. Finding "all documents acquiring values from a document" is
not possible, they can only be guessed in an ad-hoc way.
For safety / consistency with existing API, we should keep the old
ERP5Type_getSecurityCategoryFromArrow behaviour and introduce a new
script using acquired categories,
"ERP5Type_getSecurityCategoryFromAcquiredArrow".
I did this in r19639, but this can still be discussed if you want.

I discussed this with romain, and he found that another script was doing
exactly the same thing (with acquisition):
ERP5Type_getSecurityCategoryFromContent

For the same reasons, we conclude that we should:

modify ERP5Type_getSecurityCategoryFromContent not to use acquired
categories, and add ERP5Type_getSecurityCategoryFromAcquiredContent with
acquired categories.

deprecate ERP5Type_getSecurityCategoryFromArrow in favor of
ERP5Type_getSecurityCategoryFromContent, as both scripts does exactly
the same.
Remove ERP5Type_getSecurityCategoryFromAcquiredArrow, that we introduced
last week before it is used by anybody.

If there's no objections, we'll apply thoses changes in the next few days.

J?rome

Jérome Perrin

2008-03-20 19:27:41 UTC

Permalink

Hello,
The problem with a security based on acquired categories is that you
won't be able to easily regenerate local roles when a category is
changed. When the category is set on the document, we usually add an
interaction workflow on set.* to update local roles. If the category is
acquired from another document, the interaction workflow must be on the
other document, and all documents acquiring values from the other must
be updated. Finding "all documents acquiring values from a document" is
not possible, they can only be guessed in an ad-hoc way.
For safety / consistency with existing API, we should keep the old
ERP5Type_getSecurityCategoryFromArrow behaviour and introduce a new
script using acquired categories,
"ERP5Type_getSecurityCategoryFromAcquiredArrow".
I did this in r19639, but this can still be discussed if you want.

I discussed this with romain, and he found that another script was doing
ERP5Type_getSecurityCategoryFromContent
modify ERP5Type_getSecurityCategoryFromContent not to use acquired
categories, and add ERP5Type_getSecurityCategoryFromAcquiredContent with
acquired categories.
deprecate ERP5Type_getSecurityCategoryFromArrow in favor of
ERP5Type_getSecurityCategoryFromContent, as both scripts does exactly
the same.
Remove ERP5Type_getSecurityCategoryFromAcquiredArrow, that we introduced
last week before it is used by anybody.
If there's no objections, we'll apply thoses changes in the next few days.

Done in r20087 and r20088

J?rome