We are using carbon for adding roles and assigning to user accounts. In publisher when adding scopes to our api endpoints we can add roles to the scope.
When it comes to adding further roles you can't select an existing scope and edit the roles list further, it seems you have to delete the scope and start over again, maintaining any previously added roles when adding new ones in.
There is only a trash bin icon next to each scope added above the list of api endpoints, no edit icon of any sort.
Is this by design, or is there a way to edit existing scope details that we have not seen?
Thanks
No, this is by design and reported as a possible improvement. You have to delete and recreate scopes.
Related
I know I can set up a role to allow user's to only edit their own pages, then go mark the appropriate pages to be authored by the appropriate user. But then I run into multiple users per page problems.
Is there any way that you can explicitly only allow a user to edit certain (perhaps multiple) pages, while accounting for overlap in the case that more than one user may be allowed to edit the same page?
Thank you
This would be fairly complex to do programmatically, but a fairly easy solution is to create a vocabulary to apply to the pages and then use the taxonomy access control module: http://drupal.org/project/taxonomy_access to set the permissions based on terms.
I answered a similar question a few months ago, with an overview of implementing a few different access scenarios:
How do I give a specific user editing rights to a specific node?
If you just need a module that set the access permissions of a user to a node of a specific content type, then use http://drupal.org/project/content_access; if the content type is a book, then you can also try http://drupal.org/project/book_access.
Remember that installing different modules for access control should be avoided, as they tend to conflict each with the other.
If you have patience, then you can create your own custom module, and implement hook_node_access_records() and hook_node_grants() as suggested by Jeremy.
try http://drupal.org/project/coherent_access
or http://drupal.org/project/content_access
this ish is crazy!#!!!#!#!
This is also possible to do programatically using hook_nod_access_records() and hook_node_grants().
With hook node_access_record create a relm with the UIDs of the users you wish to allow. and in hook grants create a grant with the users uid in the same relm. It is not that scary and very flexable.
I'm trying to find a simple solution to a specific problem, which is a way to allow bloggers on my site to be able to control permissions on individual posts. So they could decide whether to have their post show up for all visitors, or for authenticated users only.
The closest module solution I've found so far is the Node Access module. It comes very close, but it doesn't quite do it for me, in the sense that it creates a new "grant" tab to the content type, then displays checkboxes with too many permissions options (allow a role to view, edit and delete), where I only want to display the view option, and I need it to be located right on the content edit/create page, not in a separate tab.
Unless I can find an alternative simple solution, I'll have to add a hack to the blog module or something. I can't think of any other way to do it.
Any ideas?
If you want to avoid coding and keep things simple, there are a couple solutions that come to mind.
TAC Lite allows you to associate a vocabulary with an access control schema. Each term can be associated with different view/edit access permissions for specific users or roles of users.
In this case, you would want a single term in the configured vocabulary. Set it up so that this term ("Restricted Access") when set, limits access to authenticated users only.
The advantage of TAC_lite is the flexibility of building out your access model as new requirements show up- such as having "premium subscribers" gaining access to even more restricted content.
Content Access allows you to set access control rules by content type, and override by node. I can't speak to the UI, as I've not used this mode.
In case Graysides (good) suggestion does not fit, you could do it yourself without 'hacking' the blog module by implementing hook_nodeapi() and hook_form_alter() in a custom module:
On the hooks 'load' operation, you could add a check for the nodes current access settings concerning anonymous vs. authenticated users. You'd add a property for that to the node object (be aware of potential naming clashes - you should prefix the names of custom properties in the node object with your modules name).
Via hook_form_alter(), you'd add a form element (e.g. radio buttons) to the node edit forms for your blog nodes that allows users to select the visibility, defaulting them to the new node property from above.
On insert and update operations of hook_nodeapi(), you'd then check the new property again and adjust the nodes access settings accordingly.
Note that this approach would possibly interfere with other node access module actions, so it might need some refinement. I do not recommend it - I just wanted to suggest an alternative to 'hacking core'.
I am working with a site that needs to use two different asp.net profile providers. They are both added in the web.config and the properties of each of them are listed there as well. I run into a problem when I try to enable a property that has the same name in each provider. Comment one out, and the site will at least load. Leave both in, and I get an error like:
Item has already been added. Key in dictionary: 'myfieldname' Key being added: 'MyFieldName'
The properties are entirely different (different types even), but I am missing how I would allow both to be used.
There must be some way I am missing as this seems like it could be a common problem.
I've only ever implemented a single profile system with a Web Application project. With the Website template, the functionality is out of the box. Profiles allow you to store some extra information per user when using the ASP.NET membership system. Profiles are stored in the database automatically when we add this extra information to our web.config file.
It makes sense that there would be a clash if you are using profile properties with the same names - a possible solution would be to create your own table mapping - for example, give 'MyFieldName' an alias in the web.config but map it to the real property name in your code. Since much of the functionality is out-of-the-box with the website template, you may be limited in the amount of customization you can perform.
The following links may help:
http://code.msdn.microsoft.com/WebProfileBuilder
http://weblogs.asp.net/joewrobel/archive/2008/02/03/web-profile-builder-for-web-application-projects.aspx
http://weblogs.asp.net/jgalloway/archive/2008/01/19/writing-a-custom-asp-net-profile-class.aspx
I want to allow only one type of user to access a certain content type. It's simple and I've done it before, but today I can't figure it out.
Generally this requires an access control module like Node Access. Using a module like that, you can completely hide certain kinds of content from users who aren't allowed to view them.
If you mean "read" access, you'll indeed need some form of access control module, as Eaton suggested. OG, for instance, is one access control module although quite often people don't think of it that way due to its other features.
If you mean edit/delete access, OTOH, you have these by node type vs role at admin/user/permissions.
And, of course, if you only want to hide nodes from non-admins, you can just unpublish them: only admins will see them.
In ASP.NET what's the best way to do the following:
Show certain controls based on your rights?
For a gridview control, how do you show certain columns based on your role?
I'm thinking for number 2, have the data come from a role specific view on the database.
Instead of actually using roles to hide/show certain controls, I would suggest having another layer of permissions for each role and show/hide based on those instead.
That way you can redefine what permissions a role has and won't have to change your code.
Also, this allows you to make new roles in the future and just assign a set of permissions to the role.
As for controls, yes... I would just set the Visible property on the control based on the user.IsInRole("permissionname") value.
For grids I would do the same... set the Visibility of the columns to the IsInRole boolean value.
//Delete Icon Column
gridViewContacts.Columns[0].Visible = user.IsInRole("DeleteAnyContact");
I would make create your permissions in a very granular nature.. such as
ViewAnyContact
ViewOwnContact
EditOwnContact
EditAnyContact
AddAnyContact
DeleteOwnContact
DeleteAnyContact
Etc...
If you're going the role-based route, ASP.NET (since version 2.0) has had a variety of membership controls available which might help in this scenario. Assuming (and this could well be a faulty assumption) that you're using the in-box membership provider, you can actually use the LoginView control to get #1 handled.
The way it works is that the LoginView can use RoleGroups and their associated ContentTemplates to customize the view for the user based on role. This works seamlessly with the in-box membership provider; I believe if you build your own membership provider based on Microsoft's technology it will also work. (I haven't done this latter step.)
Conceivably, you could use it for #2, but it'd wind up with duplicated code and effort, which isn't my personal preference. I think your choice of using role-specific SQL views to drive that table may be better than this option. (There are other options as well, of course, which may be better.)
I will second Elijah Manor's recommendation of using permissions instead of roles. Generally, that's my preference as well. (And I was surprised to discover that the membership provider technology didn't go to that level.) In any permission-centric scenario, though, you will essentially have to roll everything yourself. (I've done this, and while it's very flexible, the code to secure any given page can get hairy.)
EDIT: I apologize; I meant to include a link for the LoginView control. DotNetJunkies has a tutorial on it.