I'm trying to extend the OOTB Impex to remove customersupportagentrole from customersupportmanagergroup but it not working. Please help.
this is OOB Impex.
INSERT_UPDATE CsAgentGroup;UID[unique=true];locname[lang=en];groups(uid)[mode=append];description
;customersupportmanagergroup;Customer Support Manager Group;customersupportmanagerrole,customersupportagentrole,csagentgroup,csagentmanagergroup;The Customer Support Manager Group has access to the Customer Support Backoffice's Customer Support Manager Group and Customer Support Agent Group views AND/OR the Assisted Service Module.
;customersupportagentgroup;Customer Support Agent Group;customersupportagentrole,csagentgroup;The Customer Support Agent Group has access to the Customer Support Backoffice's Customer Support Agent Group views and AND/OR the Assisted Service Module.
this is my Impex to remove customersupportagentrole from customersupportmanagergroup
INSERT_UPDATE CsAgentGroup;UID[unique=true];locname[lang=en];groups(uid)[mode=append];description
;customersupportmanagergroup;Customer Support Manager Group;customersupportmanagerrole,csagentgroup,csagentmanagergroup;The Customer Support Manager Group has access to the Customer Support Backoffice's Customer Support Manager Group and Customer Support Agent Group views AND/OR the Assisted Service Module.
;customersupportagentgroup;Customer Support Agent Group;customersupportagentrole,csagentgroup;The Customer Support Agent Group has access to the Customer Support Backoffice's Customer Support Agent Group views and AND/OR the Assisted Service Module.
You are using mode=append which basically append your values to the existing collection(groups). In your case, some Impex(OOTB) may already add customersupportagentrole to customersupportmanagergroup before your Impex gets executed. Now your Impex will not override existing value, it just appends. So try using mode=replace, which basically override existing values.
INSERT_UPDATE CsAgentGroup; UID[unique=true] ; groups(uid)[mode=replace] ;
; customersupportmanagergroup ; customersupportmanagerrole,csagentgroup,csagentmanagergroup ;
; customersupportagentgroup ; customersupportagentrole,csagentgroup ;
You can do it like this, if you don't use the mode operator in groups it will replace the collection with the componenets you specify
INSERT_UPDATE CsAgentGroup; UID[unique = true] ; groups(uid) ;; customersupportmanagergroup;csagentgroup,csagentmanagergroup;
or if you put [mode=remove] it will delete the component you specify
INSERT_UPDATE CsAgentGroup; UID[unique = true] ; groups(uid) [mode=remove] ;; customersupportmanagergroup;customersupportmanagerrole;
You need to remove for existing items in your impex.
Below code remove CsAgentGroup item (thanks #FarrukChishti for your attention)
REMOVE CsAgentGroup;UID[unique=true];groups(uid)
;customersupportmanagergroup;customersupportagentrole
We need to remove only relation so we can remove item from relation type like below or update existing like other answers.
REMOVE PrincipalGroupRelation;source[unique=true](uid);target[unique=true](uid)
;customersupportmanagergroup;customersupportagentrole
You want to update customersupportmanagergroup so that any link connecting customersupportmanagergroup to customersupportagentrole is removed while the customersupportagentrole still exists in database.
Using remove query will delete customersupportagentrole from database.
UPDATE CsAgentGroup;UID[unique=true];groups(uid)
;customersupportmanagergroup;customersupportmanagerrole,csagentgroup,csagentmanagergroup
Related
I m new to liferay perform crud operation but my create method is not appering in api/jsonws . I also check my service is active by lb gogo shell command
For ServiceBuilder operations, please check if you have remote-service="true" on your entity (attributes) inside the service.xml file. If not, please add this attribute and rerun servicebuilder.
Open your {EntityName}ServiceImpl (inside of the .service.impl package) and add your operations here.
Finally, rerun servicebuilder and deploy your app. When using api/jsonws - make sure you select the right context name with the dropdown.
I'm creating a wix installer to install multiple web applications, I give the user the option to select an existing website or create a new one. So far, I have implemented the user interface and queried the IIS for the existing websites, but the problem is that I don't know how to configure these two options. I tried using conditional components where I check for a property I set in a custom action but the issue with this scenario is that I end up placing the website element inside a component which I don't want to do in case the user chose an existing website(to avoid it from getting deleted on uninstall)..I found solutions on the web for installing to an existing website or creating a new one but never the both..Can anyone help me with this?
You can create Custom action for that and set the result of it to wix property.
string result ;
session["RESULT"] = result;
then in your wxs :
<Custom Action="InstallWebsite" After='InstallFinalize'>NOT Install AND (<![CDATA[RESULT<>"Existing"]]>)</Custom>
You can create Custom action for that and set the result of it to wix property.
string result ;
session["RESULT"] = result;
then in your wxs :
With Sonata, I'm trying to use the role based security.
I want to give a group, rights for listing, editing & creating users, so I created a role with
ROLE_MANAGE_USERS:
- ROLE_SONATA_USER_ADMIN_USER_EDIT
- ROLE_SONATA_USER_ADMIN_USER_LIST
- ROLE_SONATA_USER_ADMIN_USER_CREATE
This works fine, but according to the doc, I'm understanding that a user granted with
ROLE_SONATA_USER_STAFF
Should already inherit rights for [EDIT, LIST, CREATE], but that does not seem to be the case
I also tried with
ROLE_SONATA_USER_ADMIN_USER_STAFF
Is there something I misunderstood ?
I guess that's not the case. First of all, the name of the main roles for edit depends on the services names. For example, if the service of the admin is sonata.user.admin, then the roles will be, for example:
ROLE_SONATA_USER_ADMIN_LIST
ROLE_SONATA_USER_ADMIN_VIEW
As you can see, the prefix is always ROLE (symfony 2 requirement), followed by the service name (but having the dots exchanged with underscores, and all capital letters), and ended with the prefix for the specific permission:
LIST: view the list of objects
VIEW: view the detail of one object
CREATE: create a new object
EDIT: update an existing object
DELETE: delete an existing object
EXPORT: (for the native Sonata export links)
As I can understand, there is no ROLE_SONATA_USER_STAFF predefined for edit, list and create. However, you can define it in the hierarchy, in the security.yml file:
security:
role_hierarchy:
# Setting up
ROLE_SONATA_USER_STAFF:
- ROLE_SONATA_USER_ADMIN_EDIT
- ROLE_SONATA_USER_ADMIN_LIST
- ROLE_SONATA_USER_ADMIN_CREATE
# using the staff role to create new roles
ROLE_MANAGE_USERS: [ROLE_SONATA_USER_STAFF]
I can't figure out how to add Register/Login functionality to a site in Orchard. Is there a Membership module or some configuration I need to enable?
EDIT: What I had in mind were modules along the lines of these that extend the existing User model with registration/profile functionality:
Extended Registration module: http://extendedregistration.codeplex.com/
Orchard Profile module: http://orchardprofile.codeplex.com/
It's under settings/users in the admin ui.
In the Dashboard scroll down to Settings and select Users.
Make sure "Users can create new accounts on the site" is checked and click "Save".
Once this is done log out.
Then click log in, and bellow your username and password field there will be a small text with a blue link to Register.
You don't actually need the extended registration and profile for this. Those are for adding additional information to the registration form.
This can also be done programmatically:
var registrationSettings = _services.WorkContext.CurrentSite.As<RegistrationSettingsPart>();
registrationSettings.UsersCanRegister = true;
However this will not work if you're doing it from Migrations because you won't be able to use WorkContext.
For migrations you can use IRepository for RegistrationSettingsPartRecord:
RegistrationSettingsPartRecord currentSetting = _registrationSettingRepository.Table.First();
currentSetting.UsersCanRegister = true;
_registrationSettingRepository.Update(currentSetting);
However this will no longer work as of Orchard version 1.8 as the record no longer exists. As of 1.8 one way I know of would be using ISiteService:
var site = _siteService.GetSiteSettings();
var regsettings = site.As<RegistrationSettingsPart>();
regsettings.UsersCanRegister = true;
I have a requirement to lock down access to a SharePoint library: Only users that belong to all the groups associated with the library should have read access; others should not be allowed to read.
Let's say I have a document library that concerns three projects:
12345
13579
24680
I have users that belong to one or more projects:
Joe: 12345, 24680
Jane: 13579, 24680
Jim: 24680
Harry: 12345, 13579, 24680
I need to restrict access to this library to only users who belong to ALL projects. I.e., only Harry should have access; the others should be denied. We'd use SharePoint groups named after each project to represent the 'belongs' relationship.
Edited with more detail:
We plan to create the doc lib and set up the initial security via a workflow. However, more projects may be associated with the doclib after it's created, based on info entered in a form, and people can get moved in and out of project groups by admins (e.g. for promotions, new hires....)
For now, if a form submission adds a new project after inital setup, an admin will probably create a new group if necessary, and assign it access to the doclib. Eventually, we'd do this in a workflow.
Currently, we're writing code to assign the initial security state for the site:
We scan a list of projects entered by a user into a form, create new project groups if necessary, create a site and a couple of doclibs, break role inheritance and assign our groups read access to the doclib. We add some users to each project group.
At this point, any of those users have read access. What we don't know how to do is restrict access to only users who are members of all the groups.
You've made it hard on yourself.. SharePoint nor AD works this way, I'd go back to the drawing board because this will only cause pain ;)
I would decouple management of groups and their assignment to document libraries and sync rights throughout SharePoint like Koen mentioned.
e.g. you manage group membership separate from the groups you use to connect them to document libraries. Then you need a process to enumerate over these separate groups and assign the users in there to the document libraries individually according to your business rules. Brittle at best.
You could set your document library to BreakRoleInheritance and set permissions to your items individually.
This is a example:
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite site = new SPSite("http://..."))
{
using (SPWeb web = site.OpenWeb())
{
web.AllowUnsafeUpdates = true;
SPRoleType role = SPRoleType.Reader;
SPRoleAssignment assignment =
new SPRoleAssignment(web.Groups["groupname"]);
assignment.RoleDefinitionBindings.Add(
web.RoleDefinitions.GetByType(role));
SPList list = web.Lists["name"];
SPListItemCollection items = list.GetItems(new SPQuery());
foreach (SPListItem item in items)
{
if (!item.HasUniqueRoleAssignments)
item.BreakRoleInheritance(false);
while (item.RoleAssignments.Count != 0) // remove all
item.RoleAssignments.Remove(
item.RoleAssignments.Count - 1);
item.RoleAssignments.Add(assignment);
}
}
}
});
The only way I can think of achieving this is to create a custom timer job that updates your document library every day by deleting all the rights, and then adding them again overnight. That would mean that people who join those projects will have to wait 1 day to get acces. You would just create a collection of all the users of group1, and check for each one if they exist in group 2, 3, ... and if they don't remove them from the collection.