I'm working on customizing Horizon. My goal is to, not only limit access to certain aspects of the dashboard, but also remove these components from the dashboard depending on the user role. So I'm not sure if this is even the right direction to be heading.
I'm trying to understand where it defines permissions, for example on some given Horizon component I can add:
permissions = list(getattr(instances_panel, 'permissions', []))
permissions.append('openstack.roles.admin')
instances_panel.permissions = tuple(permissions)
My question is where are these roles defined? I assume in keystone, and how, if possible, can I reference custom roles for example:
permissions.append('keystone.roles.my_custom_role')
You are on the right track. Try this:
permissions.append('openstack.roles.my_custom_role')
Related
I'm using the 2sxc News App for DNN and I'm trying to figure out how to grant users the ability to add/edit/delete news posts without also granting them the ability to change the layout or edit the module.
I tried to add the "2sxc Designers" role I've read about:
But having that role doesn't seem to change anything.
Am I doing something wrong in setting the "2sxc Designers" role and is this what I need to allow only post manipulation?
This is an advanced use case, and I can't give you the full answer, but basically what you want to do is this:
On the content-type, give the group custom permissions - so that the UI accepts changes by them https://github.com/2sic/2sxc/wiki/concept-permissions
Since the toolbars won't appear for non-editors, you'll have to make this happen in the template. So add some razor to check if people of this role. Then enable edit with Edit.Enable https://github.com/2sic/2sxc/wiki/razor-edit.enable
These blog-posts may also help you: https://2sxc.org/en/blog/post/recipe-create-public-forms-with-2sxc
I would like to write an plugin for the cockpit app. The feature i would like to add includes also an additional item in the drop-down menu. However i also would like to introduce my own permission. If the role of the user has the permission the item in menu will be shown otherwise not. Is this possible at all? And how does at look like? I checked the online documentation but couldn't find anything about it. I hope someone could help me...
The only way to introduce new permissions is through a microservice in its manifest. With purely UI you cannot add those.
As an alternative you could base your plugin on any property of the user. You probably would than want to have a second plugin to set/manage this for a user.
Out-of-the-box, an Alfresco user can read a document based on:
The document's permissions
The user's role
The user's groups
Whether the user owns the document or not
Maybe some other factors I forgot?
Now, I want to add a new factor: Whether the document is currently part of a workflow.
Alfresco's permissionDefinitions.xml allows me to define permissions based on authorities such as ROLE_LOCK_OWNER etc, but it does not seem to be the right place to add permission conditions.
I guess I will have to write some Java source code, but I am not sure what classes are responsible for this, and whether there is an Alfresco way to customize them?
So, I assume you want to somehow have nodes that are attached to a workflow have different access rights? You need to think about the behavior you want in all of the UIs and protocols you are exposing (e.g. share, WebDAV, CIFS, FTP, etc.).
If you want to set a permission on a node, you can do that via JavaScript as well as Java (See http://docs.alfresco.com/5.2/references/API-JS-setPermission.html and http://docs.alfresco.com/5.2/references/dev-services-permission.html). As was mentioned in one of the comments, you can also get the number of active workflows on a node by referencing the activeWorkflows property in JavaScript (http://docs.alfresco.com/5.2/references/API-JS-ScriptNode.html) or in Java
Depending on the specifics, I might implement this in different ways, but if all you want to do is have the permission change, you could just update it at the beginning and end of your workflow with a simple javascript call. The only thing bad about that is that it doesn't take into consideration the workflow getting canceled. You could also create a policy/behavior on an aspect you attach or even have a rule or job run that updates content based on the activeWorkflows values.
I want to restrict access to screen transitions for unauthorized user.
This is what I did:
1) I created UserGroups and added certain users to those user groups.
2) I also created certain ArtifactGroups.
3) Associated UserGroups with ArtifactGroups by 'ArtifactAuthz' entity.
4) Added certain artifacts to ArtifactGroups using ArtifactGroupMember.
I am able to restrict/allow access of screen artifacts but not able to restrict access to screen transitions.
Prepared data to add screen transition artifact into artifact group.
<moqui.security.ArtifactGroupMember artifactGroupId="CONFIG_ADMIN" artifactName="/tutorial/getTutorials" artifactTypeEnumId="AT_XML_SCREEN_TRANS" inheritAuthz="Y"/>
I doubt, I am not using proper artifactName. I also tried to find sample data for screen transitions but couldn't find any.
Please provide sample data to add screen transitions into artifact groups.
Thanks in advance.
This is not something used very often, and while it was part of the original design I've always found better ways to handle a given need. That said, it is supported. In older versions of Moqui the format is:
"${parentScreen.location}.transition_${name}"
Since that is cumbersome I changed it in commit #ed0fd6e to be more like the format used for other things elsewhere:
"${parentScreen.location}/${name}"
If you pull now from the GitHub moqui/moqui repository that is what you'd use.
I want such a mechanism that will provide different themes depends on different user roles in Liferay.Is there a way that provide me a solution that i can change theme on User roles.
Secondly i want to know that is this is possible programatically or Liferay provides custom supports with this.
any help will be greatly appreciated.
Bad choice
The right way is not to change the theme but to inject something in the page to alter the style.
It's a bad idea to change the theme at runtime depending on the user session. Poor performance due to the invalidated cache every request.
Build a custom portlet and inject it into the theme for every page. Depending on user logic that portlet can inject some javascript to alter css class of html tag.
Is it clear?
Theme is associated with layout (i.e. page). This can be observed in Layout table of liferay. So, even it can be changed using API, but not something that is different at user level, but its associated at page level.
For your requirement, If you have some fixed number of themes, then having different Sites each having one particular theme been applied.
Using Post login hook, you can check for user role and redirect to appropriate site.
Having this approach you can have completely different layout and pages as well depending on user role if you wish you.
We can also use velocity variables such $is_male, $is_female, $time_zone, $language.. to identify user group and can load different CSS file or a parent class in body tag.
Answer might be not useful for Mark who has raised this but future reader might find this useful.
Thanks