Does anyone know of any way to export user and role permissions, and then re-import them on another copy of Sitecore?
I've had a search around, and bar writing a bit of code to do this, doesn't appear to be anything immediately available ...
The permissions are actually stored on the items themselves, not the Role or User objects. There are two ways to export the object like Stephen mentioned, perform the export/import on the item you granted/revoked access to, not the role or user.
There are two ways to do this .. you can make a Sitecore package and add them to that, the other way is to use Serialization which will write text files to disk that you can then restore into another sitecore instance.
The choice very much depends on how many users / roles you have to move. If its just a few, you can use a Sitecore package but if you have a lot you will probably want to use serialization to do it.
More info about each topic can be found here..
Serialization Guide
Info on Packages
Related
Is there any way by which we can create new roles programmatically in Superset? I have checked the docs but can't find any hooks to create the roles programmatically.
I use Superset as a python library, and got the same problem a few months ago...
first you have to create a Custom Security Manager... to do this i read this tutorial https://programmer.group/tutorial-how-to-integrate-superset-in-your-own-application.html
Essentially you make the call from your superset_config.py file like this
from core_utils.security import CustomSecurityManager
CUSTOM_SECURITY_MANAGER = CustomSecurityManager
In the init method of the CustomSecurityManager() you can make the call to add_role() function... this do the trick
--
SupersetSecurityManager is the object that have available functions to manage user programatically
Sorry for my bad english, this is my first collaboration, hope this helps
We are currently moving our Auth services to AWS Cognito. As it's crucial to have the user profiles + data safe, we need to have a backup of the main user pool. We've noticed that there is an option to Import Users via a .csv file with the headers equal to the pool attributes but there is no option to create the .csv automatically. Does anyone know of a solution which automatically generates such file?The point is to protect the user profiles of accidental delete of the whole user pool (by accident, let's say a tired developer on Friday night)? I've personally tried to implement a workaround solution by doing all manual work (getting headers, users, mapping them and creating the csv) but that is not very reliable.
I know I am late to the party but leaving this here for future searches.
I too faced the same issue while working with Cognito and thus made a tool to take backups and restore them to userpools.
You can find it here: https://www.npmjs.com/package/cognito-backup-restore
This can be used via cli or using imports (incase you want to write your own wrapper or script).
Please suggest any improvements: https://github.com/rahulpsd18/cognito-backup-restore
This is still under development, as I plan to make use of Cognito User Pool Import Job instead of using aws-sdk's adminCreateUser to create users while restoring to improve upon the current implementation. But it works fine for now.
Cross-Region Cognito Replication will be implemented too once I fine tune the restore process.
Amazon has released a Cognito User Profiles Export Reference Architecture for exporting/importing users from a user pool. There are limitations:
Passwords not backed up; users will need to reset
Pools using MFA are not supported
Cognito sub attributes will be new, so if the system depends on them, they need to be copied to a custom user attribute
Federated users also pose challenges WRT sub
Advanced security - no user history is exported
No support for pools that allow the option of either phone or email usernames
No support for tracked devices
I also created a tool for this, which also supports backing up and restoring groups and relations to users:
https://github.com/mifi/cognito-backup
You can install it like this:
npm i -g cognito-backup
and use it like this:
cognito-backup backup-users eu-west-1_1_12345
cognito-backup backup-groups eu-west-1_1_12345
cognito-backup backup-all-users eu-west-1_1_12345
cognito-backup restore-groups eu-west-1_12345
cognito-backup restore-users eu-west-1_12345 Abcd.1234 --file eu-west-1_12345.json
Note that password cannot be backed up due to an AWS limitation.
To prevent accidental pool deletion you could create a Service Control Policy at the org level.
I have a question about working with CustomForms. I would like to implement a function/search in SuiteScript that would search for CustomForm by Name instead of ID. Any suggestions?
Not sure I 100% get the problem, but see if this doen't help:
Remove code from email to support case script that sets field "customForm".
Create specific role for user used to create the cases - don't assign a generic role, like "administrator".
In code for script, specify the role you created in #2 for the login/authentication.
Now, you can flip back and forth between forms from the NetSuite UI by making the needed form the default for the role you created in #2.
All other users will be unaffected, and you won't have to modify the script going forward, except if you have new functionality to add to it.
The other option is to always make the script use the standard case form. That way, you'll never really need to change it. The standard form will contain all custom fields and all standard fields. The only thing you would then need to control is the preferred form by role.
You need to do the development in sandbox environment and test it there completely before doing the production deployment. You can ask your support team to stop for few minutes while doing the deployment and then do a quick smoke test if possible.
I'm using mercurial-server to manage my repositories in the enterprise server. I created a repository for each user and I wanted each of them could give access to another, ie, each user would have access control to your projects in your repository. But in mercurial-server documentation I see that only administrators can give that kind of access.
Is that way how it works or gives to circumvent it somehow through the mercurial-server or even own mercurial(hg)?
If you want to delegate the access rights management to your users, they would need to have access to the /hgadmin repository and they should be able to modify the /hgadmin/access.conf file where the fine grained access control is located.
To my knowledge there is no way (yet) to use Mercurial-server to have silos of access-control, where a user could grant access to his/her own repository but not to other's repositories. However you should be able to develop such an extension to the system: with a hook that would extract relevant rights from, e.g., <user-repo>/admin/access.conf and copy them in a zone where another hook or a cron would select only lines concerning the <user-repo> zone (with a sed or perl or whatever you'd like), then update the real access.conf file, and finally commit and push it.
Hope it'll help.
I'm not sure if this is the correct StackExchange site for this, so I apologize if it's not.
Is it possible to create subprojects in Redmine and have it automatically inherit the member permissions from the parent project? If I've got User A as Manager and User B as Developer on the parent, I'd like it to automagically set that up on the new subproject.
I've searched high and low and can't find a way - internal or plugin - to do this.
Thanks!
That's actually very simple: All you have to do is to go into the administration panel, display the list of projects, find the parent project and use the copy button to create the sub-project. On the next page you can configure your project, pre-filled with the values of your parent project, and have some more options like copying members.
Of course this works only on creation - once you created the sub-project and you change one project, you'll need to change the other one as well. Fortunately, working with groups makes it very easy (configure access for groups, not users).
This is possible now since Redmine 2.3.0 (see issue #5605 for discussion). When creating (or updating) a project, you can simply check the Inherit members checkbox.
(This option wasn't available in Redmine when this question was asked and answered initially, so I'd be happy if you considered changing the accepted answer to this one, thanks!)
That's not possible. One of the most fundamental facts of the Redmine permission system is that users are members of distinguished projects having one or more roles. The permissions can't be inherited. In fact, the possibility to have an issue tree was added rather late and hasn't yet been reflected in the permission system.
That said, even if it could be done, permissions could only be added, as you can't take away permissions using roles (permissions from multiple roles are always added). So you would end up with only the possibility to add more permissions in subprojects, but not with less.