I am trying to return in code a list of particular entities that are shared with a team. In particular the shared views (userquery entity) objects that are being shared?
Any pointers would be appreciated.
This is what I ended up using:
RetrievePrincipalAccessRequest shareAccessRequest = new RetrievePrincipalAccessRequest
{
Principal = new EntityReference("team", myTeam.Id),
Target = new EntityReference("userquery", uvEntity.Id)
};
var shareAccess = (RetrievePrincipalAccessResponse)this.crmConnection.OrgServiceProxy.Execute(shareAccessRequest);
However the access rights that are returned are always none despite the view being shared with the team. I am not sure why?
Related
I have the following code:
var propertyInstance = new DynamicPropertyInstance()
{
DynamicPropertyId = new EntityReference(DynamicProperty.EntityLogicalName, Guid.Parse("0ceedfcc-68b2-e711-8168-e0071b658ea1")),
ValueString = jobId.ToString(),
RegardingObjectId = line.ToEntityReference(),
};
crmContext.AddObject(dynamicPropertyInstance);
crmContext.SaveChanges();
It is successfully adding a DynamicPropertyInstance to a SalesOrderLine, but when viewing the Order in the CRM UI it does not pass the validation (as it is a required property). I've not managed to find a way to make this property valid. Editing the property that I've added in the UI (resetting the value) also fails to mark the instance as valid. Adding exactly the same property through the UI does mark it as valid.
The Id of the DynamicProperty is correct, as verified by loading the 2 instance records through the SDK and comparing the properties. Rather strangely, when I load the 2 records through the SDK the one I've created in code has a validationstatus of true (even though it's not) and the one that I've created in the UI has a validationstatus of false and ValueString returns null (which is wrong). All of the other properties either match or have relevant values (such as dates, object Ids etc)
I'm probably missing a method call to recalculate whether the instance is valid or not, but I can't find anything in the documentation to support that. Failing that, it's possibly a bug in CRM
Raised a case with Microsoft support, and was given some workaround code:
//Get DynamicPropertyInstance
UpdateProductPropertiesRequest UpdateRequest = new UpdateProductPropertiesRequest();
UpdateRequest.PropertyInstanceList = new EntityCollection();
UpdateRequest.PropertyInstanceList.EntityName = DynamicPropertyInstance.EntityLogicalName;
Entity dpInstance = new Entity(DynamicPropertyInstance.EntityLogicalName, Dpi.Id);
dpInstance.Attributes.Add(nameof(Dpi.ValueString).ToLower(), "Blarg");
dpInstance.Attributes.Add(nameof(Dpi.DynamicPropertyInstanceid).ToLower(), Dpi.Id);
dpInstance.Attributes.Add(nameof(Dpi.RegardingObjectId).ToLower(), new EntityReference(SalesOrderDetail.EntityLogicalName, line.Id));
dpInstance.Attributes.Add(nameof(Dpi.DynamicPropertyId).ToLower(), new EntityReference(DynamicProperty.EntityLogicalName, dpId));
UpdateRequest.PropertyInstanceList.Entities.Add(dpInstance);
crmContext.Execute(UpdateRequest);
Basically, it looks like you have to re-set or re-attach the entities for CRM to pick it up, so this is a workaround for a bug in CRM
I want to implement User and Role Manager in VS 2015 using the Identity.EntityFramework": "3.0.0-rc1-final".
Among others I have created a class IdentityManager.
My main problem is creating a method to check the existence of a Role as follows.
public bool RoleExists(string name)
{
var RoleManager = new RoleManager<IdentityRole>(new RoleStore<IdentityRole>(new ApplicationDbContext()));
return RoleManager.RoleExists(name);
}
I keep getting the error on new RoleManager<IdentityRole>:
There is no argument given that corresponds to roleValidators, keyNormalizer, errors, logger,contextAccessor"
Yes, basically all the parameters I am not specifying but I have no idea how to approach these.
I am very new at this and have been searching and trying for days now, if someone can just point me in the right direction I am willing to do the legwork and testing, I just need some documentation.
I am having a similar issue - it looks like the roles are not the best option in identity 3.0
This thread (ASP .NET 5 MVC 6 Identity 3 Roles Claims Groups) helped me get something working, but its sad that this is not better documented.
Here are my attempts at improving that. Asp.net.Identity (3.0.0.0-rc1-final)
in Startup.cs --> ConfigurationServices
//Define your policies here, they are strings associated with claims types, that have claim strings...
//they need to be in AspNetUserClaims table, user id, department, Dev to be allowed access to the Dev policy
//add the auth option, below that makes it work, and in the api controller, add the
//[Authorize("Dev")] attribute
//services.AddAuthorization(
// options =>
// {
// options.AddPolicy("Dev", policy => { policy.RequireClaim("department", "Dev"); });
// });
Is there a way to define a connection to a new Solr core on the fly, based on dynamic data?
We have a scenario where our Solr installation has multiple Cores/Indexes for the same type of document, separated by date (so a given week's documents will be on Index 1, the previous week's on Index 2, etc).
So when I receive my query, I check to see the required date range, and based on it, I want to query a specific core. I don't know in advance, at startup, which cores I will have, since new ones can be created dynamically during runtime.
Using the built-in ServiceLocation provider, there's no way to link two different Cores to the same document class. But even if I use a different DI container (currently Autofac in my case), I still need to specify all Core URLs in advance, during component registration.
Is there a way to bypass it except for always creating a new Autofac Container, generating the ISolrOperation<> class from it, and releasing it until the next time I need to connect to a core?
Mauricio Scheffer (developer of Solr.Net)'s comment confirmed that there's no built-in support for connecting to different index URLs on the fly. So instead of instantiating the internal objects myself, I used a hack on top of my existing Autofac based DI container:
public ISolrOperations<TDocument> ConnectToIndex<TDocument>(string indexUrl)
{
// Create a new AutoFac container environment.
ContainerBuilder builder = new ContainerBuilder();
// Autofac-for-Solr.Net config element.
var cores = new SolrServers
{
new SolrServerElement
{
Id = indexUrl,
DocumentType = typeof (TDocument).AssemblyQualifiedName,
Url = indexUrl,
}
};
// Create the Autofac container.
builder.RegisterModule(new SolrNetModule(cores));
var container = builder.Build();
// Resolve the SolrNet object for the URL.
return container.Resolve<ISolrOperations<TDocument>>();
}
How can I "pair" multiple users, and have them access the same data - perhaps some of the users in a group having read only rights? As a use case, think of a family sharing calendars, each using their own login, but being able to see each other's calendar.
You should have a look at Roles and Security in the Parse docs.
I'm no expert, but I would assume that you would create a role for a family and then restrict the access to either classes or objects (depending on your approach) with Access Control Lists. In that way you can have a group/role that has the same permissions for same objects and classes.
Adapted from the docs:
Creating a role
// By specifying no write privileges for the ACL, we can ensure the role cannot be altered.
var roleACL = new Parse.ACL();
roleACL.setPublicReadAccess(true);
var familyRole = new Parse.Role("MyFamilyRole", roleACL);
familyRole.save();
Then
var calEvent = new Parse.Object("CalendarEvent");
var familyACL = new Parse.ACL();
familyACL.setPublicReadAccess(false)
familyACL.setPublicWriteAccess(false)
familyACL.setRoleReadAccess("MyFamilyRole", true);
calEvent.setACL(familyACL);
calEvent.save();
This can of course be done more efficiently by using defaultACLs and other functionality. But these are the basics.
Btw, I reference the JS api, since you didn't specify a platform.
I get System.NotSupportedException: An attempt has been made to Attach or Add an entity that is not new perhaps having been loaded from another DataContext when I want to update an object's with child entities.
The scenario is like this:
I have a SubscriberProvider that allows me to create subscribers.
var provider = new SubscriberProvider(); // Creates a new repository with own datacontext
var newSubscriber = new Subscriber
{
EmailAddress = emailAddress,
};
newSubscriber.Interests.Add(new Interest{
Id=1,
Name="cars"
});
provider.Subscribe(newSubscriber);
On a normal subscribe page, this works fine.
Now I have a linq2sql Member class(retrievable by a MemberRepository) and I want to extend it to have a helper subscribe method like so:
var repository = new MembershipRepository(); // Holds its own datacontext
var member = repository.Get("member1");
member.Subscribe(); // transfer member's info and interests to subscriber's table
The exception occurs when SubscriberProvider tries to add interests of the member.
Commenting out
newSubscriber.Interests.Add(new Interest{
Id=1,
Name="cars"
});
will make member.Subscribe() work.
member.Subscribe() is simply:
public void Subscribe(bool emailIsVerified, bool receiveEmails, bool sendDoubleOptIn)
{
var provider = new MailingListProvider();
provider.Subscribe(EmailAddress, emailIsVerified, receiveEmails, CountryId, sendDoubleOptIn, ConvertInterests(MemberInterests.ToList()));
}
So what's causing the child entities(Interests) to lose their datacontext when I do member.Subscribe() and how do I go about fixing this?
It seems there's some code missing here, but I'll take a stab anyway because I think I have an idea what's going on.
If you have a different DataContext created for your MembershipRepository and your SubscriberRepository you're going to have issues related to entities "having been loaded from another DataContext." (as the Exception you posted points out). You can't just take an object out of one DataContext and save it into another.
It seems that you might have an architectural issue here. Should these 2 repositories actually be separate? If so, should they have completely different DataContexts? I would probably recommend using Dependency Injection to inject your DataContexts into your Repositories. Then you can decide how to cache your DataContexts.
That line of code you commented out is being flagged by the DataContext as a new record, even though it's likely that the record already exists, due to the error message.
Change the line to:
newSubscriber.Interests.Add(DataContext.Interests.Where(a => a.Id == 1).Single());
Now, the DataContext will know that record is one that already exists, and won't try to add it as an Insert to the ChangeSet.
Found the solution to this myself. Turns out it was the ConvertInterests() method causing it. The converted interest object had an invalid declaration which compiled ok.
Thinking the code was simple enough, I didn't create a test for it. I should have known better!