Any idea what ACE entry (path, privilege, permission) I should add for a specific group to be able to see (read only) the list of ALL/any active workflow instances?
The list of active instances is under this url
http://xxxx:4502/libs/cq/workflow/admin/console/content/instances.html
I added a jcr:read allow permission on the following paths /etc/workflow/instances, /var/workflow/instances for my group but I still can't see the list of active workflow instances.
You can't make it work by manipulating ACEs.
The AEM Workflow Engine supports a notion of a 'superuser' which can access all workflows, started by any user. Regular users can only see the instances they started.
The list of workflow superusers is controlled by com.adobe.granite.workflow.core.WorkflowSessionFactory
You can define a custom group and add it to this list. Then, providing that the user has read permissions on workflow models and instances, and is a member of a supergroup, they should see all the workflows.
Related
I scrolled through the documentation of KeyCloak and also set it on my machine to explore.
I also explored fine-grained permissions however I didn't get much detail in documentation around the n-level of nested hierarchies.
Here https://www.keycloak.org/docs/latest/server_admin/ this talks about limiting an admin user to particular client management, however, I want certain users, within the client, to be able to create accounts but with scopes and attributes limited to what's assigned to themselves.
For an example:
For a client(ERP>Transactions) we want to create an Org(our customer) Admin who in return will create teams and team admins. Team admins shall be able to invite their teammates in there.
Now I just want to know if only Keycloak can be used to make sure a user in one Org shouldn't be able to create a user in some other org, in the same way, a team admin shouldn't be able to onboard/invite a user in some other team.
Because if Keycloak in principle can't handle this, our team will start writing custom logic in our application code base for this.
I have checked the docs from Microsoft for AzureDevops and I understand how to manage permissions for a branch.
What I would like to know is if a user is automatically added with Edit Policies permission to Allow as he creates the branch (assuming a normal user not admin, and he's not inheriting this permission) ?
If the answer to the above question is yes, then is there any case when a second user could be added to the list of branch permissions automatically ? without an administrator adding it explicitly ? I couldn't find this in the docs anywhere.
*picture from msdn
Yes, for each branch's permission setting, you could directly manage that user's or create a group then add that consultancy in the group, manage the group's permission.
In other words, without adding it explicitly, the user B could also be added to a group.
You just need to make sure that you are not part of any groups that have the complete privilege Denied.
In Azure DevOps, Deny trumps Allow.
Unless you're a member of the Project Collection Administrators group on your organization, membership in a group that explicitly Denies any permission will deny your permission, even if you are in another group that explicitly Allows you the permission and even if you as an individual user are granted Allow on that permission.
We usually add developer to Contributors.
For the Inheritance part, you could turn on your inheritance and clear explicit with single click for each branch which have explicit permissions.
After this, Contributors Group in other branches will totally inherit the permissions set by root path of your repo/workspace. For example, if root path are Allow, your branches should be Allow(inherited), if it's Deny, your branches should be Deny(inherited).
If a permission isn't directly allowed or denied for a user, then it may be inherited in two ways.
Users inherit permissions from the groups to which they belong. When
a permission is allowed for a user directly or through membership in
a group that has that permission, and it is denied, either directly
or through group membership, the permission is denied.
Members of Project Collection Administrators or **Team Foundation
Administrators** retain any allowed permissions, even if they belong to
other groups that deny those permissions.
Object-level permissions that are assigned for nodes of a hierarchy -
areas, iterations, version control folders, work item query folders -
are inherited down the hierarchy. That is, a user's permissions that
are set at area-1 are inherited by area-1/sub-area-1, if the same
permission is not explicitly allowed or denied for area-1/sub-area-1.
If a permission is set explicitly for an object, like
area-1/sub-area-1, then the parent node is not inherited, regardless
of whether it is denied or allowed. If it's not set, then the
permissions for that node are inherited from the closest ancestor
that has the permission explicitly set.
More details please take a look at our official tutorial here: Inheritance and security groups
I need to give someone access to create work items ONLY. They are a 'stakeholder' user. Currently I cannot restrict them from seeing Variable groups OR Task Groups. I cannot see any deny permmisions and the person is in no other groups. I added them to an organization group with DENY permissions in all 4 Pipelines permissions. Still the user can see them
I added them to an organization group with DENY permissions in all 4
Pipelines permissions. Still the user can see them
That's caused by that the permission listed here used to restrict the build view, such as build definition and etc. But, Variable group and Tasks group does not belong to build, they just be linked/called into the build. Set the View build resources as deny could not restrict these objects' permission. For example, Azure Key Vault's view permission could not be restricted by deny the permission of build. It just can be changed in Azure portal.
These function( such as variable group, task group, key vault and etc) which be linked/called into build called object. To modify its permission, you must go objects' security page to change it.
Since what you are focusing is Variable group and Task group, unfortunately, viewing these objects belong the basic permission of Stackholder and could not be restricted in security configuration.
As you can see that there's no permission to restrict View. So, restrict stackhokders view it could not be achieve.
For security, I think you can change their level as Project reader to restrict them do change to them.
I'm working with Shopware.
I've added a new attribute "proxy" to the s_core_auth table for each user in order to show the ability to get access to the Customer Module in the backend, so that if a user is not selected as "proxy" he/she won't be able to make changes in that module.
I need help to understand what I need to write in my plugin's code (maybe having only a Subscriber file.)
I'll be very grateful!
Adding a custom column to the s_core_auth table is not a good idea. What you're trying to achieve can be done with user groups and group rights. From the Shopware Documentation:
With User administration you are able to create new users in the backend and control access rights to areas, modules and plugins in accordance with certain group policies that you define per ACL (Access Control List). Within the ACL you have the possibility to control precisely which user is able to perform which activity. Thus, it is possible to assign certain reader rights to an administration group without granting them authorization to edit or delete.
You can find instructions for User administration inside the Documentation.
I'm using Typo3 6.2 and I have added a user account (backend user). When I now login with this new user I get the error message "no module found". When I login again with my admin account everything is fine. How can I fix this?
You have probably created an unprivileged user (editor). You need to explicitely give users access to
Backend modules
Subtrees of the page tree
Folders
Tables
and so on.
To do that, you usually create a backend user group, set the permissions for this group, and assign it to the user.
You can create the group either on the root page (id 0) as record or in the user management module, where you assign the groups to users.
There are two functionalities two make pages visible for users/groups:
You need to add the root of the subtree a groups should be able to use to the group as a mount point.
You need to give the group the right to view/edit/delete/update the pages. You can do that as admin in the "Access"-module. It's similar to the Unix owner/group concept.