Currently we have a user guide sitting in Confluence. We want to give access to this page to all users of the product. What is the best way to do this?
Do I put the user guide into its one space and make it public. Then would I need to make a group defining all my users on our product?
It would be ideal if the users did not have to log into confluence in order to view the user guide. The most important piece is we do not want to give access to the user guide to everyone to view.
If you want to grant access to the users of that product, you need to create a group, and then, give access to only that group. If users don't need to log into Confluence, then, anyone could access.
Another approach is to use Comala Share It (disclaimer, I work in Comalatech). This add-on allows you to create a unique URL, which could be shared with the users of your product, so only them could access. Of course, if the URL is shared with anyone outside the group, that person could access too. Guess the public URL is not possible, since it uses a secure token.
Regards,
Gorka
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'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 don't see an easy way to grant permissions to another user. It seems to be quite convoluted at the moment, and I wonder if I'm missing something obvious.
Say I want to invite another user to share a Realm. First I would have to ask the other user for their identification, then I would create the permission object, and then finally I would give the other user the address of my realm.
It would be great if I could share some sort of permission token via text message and let the new user register themselves. I suppose I could do that if I created another "User" which represented the shared group, and merely share this abstract user's credentials. It feels a bit hacky that way, but it seems easier to do.
I was hoping the demo application of the shared drawing environment would hold a clue, but after looking at the source code, it turns out both devices are logged in as the same user.
Am I missing something? Given the demo Draw application, how would one user practically invite a second user to join in their shared drawing environment? It seems like there would have to be a whole set of convoluted permissions and url/identification sharing handshakes.
Thanks for asking the question! Today, you will need to create a shared Realm that all users would input their user IDs into and have access to. This way any user can look up an ID and share access to another Realm.
We realize the limitations and are working on offering a number of improvements. The first is pretty close to what you describe, called a PermissionOffer object where you can inform the Realm Object Server you want to grant access to another user for a given Realm(s). The server will then provide a token you can share via any means with the other user. That user can then use the token to create a PermissionOfferResponse object and accept the access grant. This is coming soon, so stay tuned!
Later, we plan to offer a way to lookup user IDs so you don't have to replicate all of them in a shared Realm (see this issue).
I want to create a new user group.
The members in this user group can create new users and new groups.
I think creating users or groups require admin permission. This user group does not have other admin permission except creating, editing and deleting user,group. Does alfresco provide this kind of group in alfresco community 4.0c? How can I implement it? How to add a new group with specified permission? I really appreciate for help.
You could add a custom role in permissionDefinitions.xml but I don't think that would help in this instance, since the ability to create users and groups plus the other administrative actions are hard-wired to the built-in administrators role.
Instead, you could create a custom web script which performs a check to see if the current user is a member of your custom security group. Since the authenticated user may not be a repository admin (and probably isn't) then you would need to use something like this Sudo tool for Alfresco webscripts to temporarily give them permission to create the objects.
You would need to be competent in Java webscript development in order to implement this. There are some good resources on the Alfresco wiki, documentation and training materials available online.
You cane manage that through Alfresco Share. In your Alfresco installation directory:
/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/model/permissionDefinitions.xml you'll find the permissionDefinitions.xml file. Through that file you can manage your custom roles for Alfresco users and groups.
Here, in this WIKI you can find some hints about what you need to change to accomplish that.
Hope it helps. The wiki helps here, if you need some better explanation please let me know.
I'm making a application for facebook that will be used for academic research. Right now when the user goes to install the application I'll request additional information which is stated in the extended permissions.
I would perfectly understand someone not wanting to give out certain aspects of this information (It's just used to gather statistics about people taking part , education, religion etc.)
Does anyone know the best way to filter the permissions? For instance maybe someone is willing to give their age but not education. Therefore can I remove the education request from my application install request dynamically?
If you want to ask the user for only those permissions that he wants to give, you can take input from him before redirecting to Facebook login. You can generate the url for requesting permissions based on this custom set of permissions using the 'perms' attribute of the <fb:loginbutton /> tag or pass the list of permissions you want to the $facebook->getLoginUrl(array('req_perms' => $perms)) call.
To keep track of permission changes, you can use the realtime updates offered. You can know more about it here.
You certainly could build an up-front permissions matrix that the user could cherry-pick from. And that would probably be the way to do it, since you can't do anything to customize the permission challenge that the Facebook Platform generates.
The trick would be keeping track of which permissions the user granted in the given access token you'll receive from back from the Platform. Especially since users can change the permissions granted to your application w/o visiting the application itself - so you'll want to be hooked in to that info via the Real Time Updates.