Is there a quick way (catalog search) to list all the users/groups that have Review portal content permission on a content object?
It's not possible without adding a new index. Take a look at the approach on that product: https://pypi.python.org/pypi/collective.portlet.truereview/
You cannot do this with a catalog query, since the only security relevant index in the catalog is "allowedRolesAndUsers" by default. This index only handles the "View" permission.
You can add your own index, with the exactly same implementation as the "allowedRolesAndUsers" Index, but check for "Review portal content". See allowedRolesAndUsers implementation
If you do so, you have to patch the reindexObjectSecurity method, otherwise your index will not be updated on security relevant changes, like change roles thru the sharing view.
Here is an example how to patch it for Archetypes content using collective.monkeypatcher
Related
I try to manage the access rights for users to edit or view different articles.
Articles can be created dynamically and the rights should be editable for every article.
In my case, I have a User object and multiple other objects (Article, and more...).
I need to check if a User can read or write any kind of object.
I actually see there is a method Voters, but they only can manage User groups?
Can somebody help me?
A Voter can decide almost anything - usually it's based on a user's permission, but it doesn't have to be - I've used one as a 'feature flag' check, with a value fetched from a configuration, or database entry to show something - or not, as an example.
The page on voters has an example on viewing, or editing a database record (a Post entity, via a $this->denyAccessUnlessGranted('edit', $post);.
In your instance, the voter would be passed the 'attribute', the object (Article, etc) you want to check on, and gets the current user from a service. If that user has the appropriate permission to read/edit/delete the Article or other object, it returns true.
I have an entity type "Post" and I would like to create a view that will show one random Post with a given category. I created a Data pipeline that grabs all posts and I created a view with ListPresentation = a "TemplateSettings" entity type that lets me choose categories.
I planned to use the Razor template to filter the items for those matching the categories in List.Presentation.Categories. But, I can't seem to reference List.Presentation.Categories. I get an error that System.Collections.Generic.List doesn't contain an entry for "Presentation". When I use #ListPresentation, the whole object in null... so #ListPresentation.Toolbar, etc. all throw errors, despite me having set a "Demo Item".
Can anybody see what would be wrong with this setup? How do I reference List Presentation stuff in Razor?
Thanks.
I figured this out... The direct thing seems to be "ListPresentation", but the snippets use "List.Presentation". Still, it wasn't working in my case because I was using a data query that didn't include the module data. So, I had to modify that query to include the module data as well as the full list of entities, regardless of the module. Then, I got the full list from one data stream, and the ListPresentation fields were available.
Note also that you can use ListContent.Presentation - that would be the newest, most consistent API which always places Presentation information as a property of the entity it's describing.
I've to list, in specific folders or collections, objects expired also to anonymous users.
You know, portal_catalog returns only brains not expired. It's a useful behavior but not in this case...
To force the Catalog to return also expired contents, we've to pass a specific parameter: show_inactive.
Browsing the folder_listing (&family) code I noticed that it's possible to pass, via request, optionals parameters (contentFilter) to the query/getFolderContents. It's a nice feature to customize the query avoiding the creation of very similar listing templates.
I suppose it's necessary to create a marker interface to mark context (folders or collection) where I want to list also expired contents. For ex. IListExpired.
I imagine to ways:
1) to make a subscriber that intercepts before_traverse and , in the handler, a test to verify if the context implements the IListExpired. In positive case I made a
request.set('folderListing', {'show_inactive':True})
2) to make a viewlet for the IListExpired that in the call set
request.set('folderListing', {'show_inactive':True})
What's the best way? I suppose the first one could be an unnecessary overhead.
Vito
AFAIK, these are two separate thing: folderListing uses a method available to all CMF-based Folderish content types; show_inactive is an option of the Plone catalog, so you're not going to make it work as you're planning.
I think you should override these views and rewrite the listing using a catalog call.
you better use a browser layer for you package to do so or, a marker interface as you're planning.
We have a content type (lets call it, MyFolder) that could contain any other content type registered in the site except for MyFolder itself.
what's the simplest way to accomplish this?
registering a new workflow and setting guards?
removing the Add MyFolder permision of the content type from the object with an event at creation time?
filtering the content type from the list of addable content types in the object? how?
none of the above? how then?
I guess point 3 should work fine, set the "Filter content types" flag on MyFolder and select all others that should be addable in "Allowed content types" of MyFolder
Of course if you add other content types, you have to manually extend the "Allowed content types" of MyFolder.
Another solution could be to set the localallowedtypes on every instance of MyFolderusing an eventhandler zope.lifecycleevent.interfaces.IObjectCreatedEvent.
In this event handler you can check for the parent and set the local allowed types.
Then you have to make sure, that your "normal" user cannot modify the local allowed types by uncheck the Modify constrain types permission.
But also here you have to manage new content types manually.
Yet another solution:
If your are using dexterity types, there is a TypeSettingsAdapter (https://github.com/plone/plone.app.dexterity/blob/master/plone/app/dexterity/browser/types.py)
You can register your own adapter for your specific type.
I think than point 3 has some complexity and turnarounds because you need to revoke Modify contrains types permission but maybe that is not the intended behavior because that way you are restricting user to modify all the locally allowed types besides MyFolder, and finally the user could find workarounds for this limitation... for example, MyFolder -> Folder -> MyFolder
point 2 is more simple, you just revoke one permission with an event handler when a new MyFolder is created, since you are revoking the permission and disabling acquisition for that perm. there is no easy workarounds to avoid the limitation, and the user could still use the configuration of locally allowed types for every addable content type but MyFolder.
I have a classic 3-tier ASP.Net 3.5 web application with forms that display business objects and allow them to be edited. Controls on the form correspond to a property of the underlying business object. The user will have read/write, readonly, or no access to the various controls depending on his/her role. Very conventional stuff.
My question is: what is the object-oriented best practice for coding this? Is there anything more elegant than wrapping each control in a test for the user's role and setting its Visible and Enabled properties?
Thanks
You'll want to drive this off of data, trust me. You'll need a lot of tables to do it right, but it is so worth it in the end. Having to crack open code and edit a bunch of if-statements every time the business wants to change permissions is a killer.
You'll want a table for your main high-level types, things you probably already have business object clases for. Then a table for each status of them. Then a table for the fields of these classes. Then a table for user roles (admin, guest, etc.) Finally a table for the permissions themselves. This table will have columns for business class, status, field, user role, and then what permission they have. For permissions I would go with one field and use an enum: Hidden, ReadOnly, Editable, and Required. Required implies Editable. Anything but Hidden implies Visible. Finally put a Priority column on this table to control which permission is used when more than one might apply.
You fill out this table with various combinations of class, status, field, role, and permission. If a value is null then it applies to all possible values. So you don't need a trillion rows to cover all your bases. For example, 99% of the time, Guest users are read-only users. So you can put a single entry in the table with only the Guest role specified, everything else is null, and set it's Priority nice and high, and set the permission to Read Only. Now for all classes, all statuses, all fields, if the user is a Guest, they will have Read Only permission.
I added status to your list of concerns because in my experience, business all the time wants to constrain things by an object's status. So maybe users can edit an item's name while it is in Draft status, for example, but once it is in Posted status, the name is no longer editable. That is really common in my experience.
You'd want to bring this table into memory and store it in the app's cache, because it's not going to change very often, if ever, unless you do a whole new version.
Now the above is going to handle 90% of your needs, I suspect.
One area that will have to be handled in code, unless you want to get really fancy, is the cases where a user's permission is determined in part by the value of fields in the object itself. So say you have a Project class, which has a Project Manager class. Now the Percent Complete field of the class is basically read-only for everybody, except the Project Manager. How are you going to handle that? You'll need to provide a way to incorporate specific instances of a class into the decision making process. I do this in code.
To work properly, I have found that access levels should be in this increasing order:
NONE, VIEW, REQUIRED, EDIT.
Note that REQUIRED is NOT the top level as you may think it would be since EDIT (both populate & de-populate permission) is a greater privilege than REQUIRED (populate-only permission).
The enum would look like this:
/** NO permissions.
* Presentation: "hidden"
* Database: "no access"
*/
NONE(0),
/** VIEW permissions.
* Presentation: "read-only"
* Database: "read access"
*/
VIEW(1),
/** VIEW and POPULATE permissions.
* Presentation: "required/highlighted"
* Database: "non-null"
*/
REQUIRED(2),
/** VIEW, POPULATE, and DEPOPULATE permissions.
* Presentation: "editable"
* Database: "nullable"
*/
EDIT(3);
From the bottom layer (database constraints), create a map of fields-to-access. This map then gets updated (further restrained) at the next layer up (business rules + user permissions). Finally, the top layer (presentation rules) can then further restrain the map again if desired.
Important: The map must be wrapped so that it only allows access to be decreased with any subsequent update. Updates which attempt to increase access should just be ignored without triggering any error. This is because it should act like a voting system on what the access should look like. In essence, the subsequent layering of access levels as mentioned above can happen in any order since it will result in an access-level low-water-mark for each field once all layers have voted.
Ramifications:
1) The presentation layer CAN hide a field (set access to NONE) for a database-specified read-only (VIEW) field.
2) The presentation layer CANNOT display a field when the business rules say that the user does not have at least VIEW access.
3) The presentation layer CANNOT move a field's access up to "editable" (nullable) if the database says it's only "required" (non-nullable).
Note: The presentation layer should be made (custom display tags) to render the fields by reading the access map without the need for any "if" statements.
The same access map that is used for setting up the display can also be using during the submit validations. A generic validator can be written to read any form and its access map to ensure that all the rules have been followed.
I have often found that this is really the only real easy and understandable way to do it, as your interface needs to modify based on the information and level of editing that they can complete.
I do find typically though that depending on the needs, you can interject the "cannot edit" information by passing role information to the business level if you have plans to move to different presentation levels. but this adds complexity, and if you are only building for one interface it would most likely be overkill
For the website menus we can have different menus based on users role by using the Sitemaps. For controls like Buttons we will have to hide them using their Visible property. I think a good idea will be to create a server control (Button) and expose the Role property. This will hide the Button if the user is not in the correct role.
My first instinct for doing this in a more OO way would be to handle your roles and their implementations for this purpose (control permissions read/write/etc) is to use the abstract factory pattern for your roles. I will be happy to explain the ins and outs of what I am talking about if you'd like but there are probably 900 examples on the web. Here is one link (disclaimer: it's my blog but it does happen to talk to using abstract factory for roles specifically)
Using something like this you could then use a number of methods to display the correct controls for each of your business object properties with the correct attributes (read/write/hidden/displayed/etc).