I am really new to MS Dynamics CRM .. and am stuck with understanding the Relationship and Mapping section.
I want to map the "city" field from Account entity to a "city" field in my custom entity "Custom".
For that I navigate to Account entity settings and create a 1:N relationship with related entity as "Custom" and then map the two fields.
Just like how all related data from "Lead" entity gets transferred to "Opportunities" after "Qualify", I want my custom "city" field to be filled with "city" from "Account" after i create a new account record.
This has something to do with workflows right?
Please correct me if I am wrong anywhere.
It sounds like you want to create a N:1 relationship on your Custom entity which points to the Account entity. If you are not looking for a lookup field, or if the entities are otherwise already related, then the “Mappings” feature of the relationship may be worth looking into. Keep in mind that this type of mapping only works when you are creating the “child” record from the “parent” record (with the parent form open). If you create the record “stand-alone” it won’t auto create the mapping. You can use workflows, however they run asynchronously and you may not see the result right away (which can confuse end users). Aside from that your options are JavaScript (not 100% reliable) or a custom code a Plugin.
Related
I have sample project for identity customization using
Install-Package Microsoft.AspNet.Identity.Samples -pre
command. But, for this project I have a general ApplicationUser class representing all the users of my application. What if I have different categories of users. For example, I may have Teacher and Student entities and data representing both the entities will be different. How can I customize my application to store data for both the entities having all the features of ApplicationUser?
One way that I think is inheriting both the classes from ApplicationUser and then doing appropriate changes in IdentityConfig.csand defining Controllers for each of them. Is there any other efficient way of doing this?
What if I want to use the built-in authentication and authorization features but using database first workflow?
First, you want to know how to create "types" of users. The way you would do that is exactly how you expected: inherit from ApplicationUser. By default, this will result in a single "users" table with an additional Discriminator column. This column will store the class type that was persisted, i.e. "Teacher", "Student", or "ApplicationUser", and EF will utilize this information to new up the right class for each particular record.
One thing to note with this, though, is that you need to be aware of how UserManager works, namely that it's a generic class (UserManager<TUser>). The default AccountController implementation you have from the sample defines a UserManager property on the controller which is an instance of UserManager<ApplicationUser>. If you use this instance with something like Teacher, it will be upcast to ApplicationUser. In particular if you were to do something like UserManager.Create(teacher), it will actually save an ApplicationUser, instead (the Discriminator column's value will be "ApplicationUser", rather than "Teacher"). If you need to work with the derived user types, you'll need to create separate instances of UserManager<Teacher> and UserManager<Student> for that purpose.
Next, you want to know if you can use a "database first workflow". To answer that, we need to define exactly what that means. EF has what it calls "Database First" which employs EDMX to represent your database entities. This in particular is incompatible with Identity. However, despite the name, what EF calls "Code First", can work with an existing database just as well as create a new one. In other words, yes, you can use an existing database, if you prefer, but no you cannot use "Database First", in the EF-sense. For more information about using an existing database with Code First, see my post.
I need to do a many to many relationship in my first Access 2013 web app.
I have a Parents table and a Students table. Each student can have two parents and each parent can have more than one student in the school.
Thinking like a seasoned Access desktop developer I took the usual route of creating a parents_students table to link the other two then hit a wall. How do I make the view show the relationship?
I found this topic: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/ccda03e3-a57b-4128-be72-f469c8ec30af/access-2013-web-app-handling-many-to-many-relationships?forum=accessdev
When I tried it, it is not doing what I want, or I am doing something wrong.
Seems like a very fundamental thing to be able to do.
Got an answer over at the MSDN forums. Link Here
Create a Parents_Students table with three fields
ID: AutoNumber
Student: Lookup the name field in the student table
Parent: lookup the name field in the parent table
To the Students View, add a SubView and add a tab called Parents. In the Data parameters set the Data Source to the Parents_Students table and the related field to Student.
Repeat the same procedure on the Parents View but use parent as the Related Field.
I have some points on a map with associated informations contained by Core Data, to link the points on the map with the associated info, I would like to have an ID for each point, so in my entity, I would need some ID property, I have read that Core Data has it's own IDs for every managed object but I'm wondering wether or not it would be a good approach for me to directly use them or if I should create my own ID system ?
If you think I should create my OWN ID system, how would I do that ?
Thank you.
CoreData is not an relational database and you should avoid thinking about own ID’s. You may need them only for syncing purposes with external databases. For more precise answer, you should write how your model looks.
[edited after comment]
I don't see that you need any relations. Let's sat you have MapPoint entity with lat, and long properties. If there is only one user note, you just add another property to it like notes. If you have many informations (many records) stored with one MapPoint you need to add Notes entity with properties note and mappoint and make a relation between them. When you insert new Notes object into CoreData you set mappoint property to already existing MapPoint object (fetched after user tap).
I have one custom entity in CRM 2011. My requirement is to create a lookup field(say Customer) for this entity like Out of the Box Customer in Case entity which is pointing to both Account and Contact records. How can I create this custom Customer field?
Sadly this is not possible. For custom lookups you have to decide which entity is the target.
In your case, you would have to define two lookups (one for each type). This is by the way the same behavior which is used by the customer lookup. They are only hidden from your eyes.
If you want to see this feature in future versions, you could support these requests on connect:
Custom Composite Lookups (multi-relationship in 1 lookup)
Give me the ability to create a lookup on the 'Customer' entity
Expand the 'Customer' entity to other entities
I am designing an application that will display dynamically-generated forms to the user who will then enter values into the form fields and submit those values for persistence. The form represents an employee evaluation.
One use case allows an administrator (from HR) to define the form fields. They should be able to create a new form, add/remove fields from a form and mark a form as 'deleted'.
The second use case is when a manager views the form and enters values into the form fields for a specific employee. They should be able to save the values at any time and recall the saved values when viewing the form again for the same employee.
Finally, when the manager is satisfied with the values they've entered for that employee, they can 'submit' the form data which persists the flattened data into the data warehouse for reporting purposes. When this is done, the 'working' copy of the data is removed so the form will display empty the next time they view it for that employee.
I am not concerned with the front-end at this point and working on the back-end service application that sits between the client and the data store. The application must provide a course-grained interface for all of the behavior required.
My question is how many aggregate roots do I actually have (and from that, how many repositories, etc)? Do I separate the form definition from the form data even though I need both when displaying the form to the user?
I see two main entities, 'EmployeeEvaluationSchema' and 'EmployeeEvaluation'. The 'EmployeeEvaluationSchema' entity would have a collection of 'FieldDefinition' value objects which would contain the properties that define a field, the most basic being the name of the field. The 'EmployeeEvaluation' entity would have a collection of 'FieldValue' value objects which contain the values for each field from the definition. In the simplest case, it would have a field name and value property. Next, the 'EmployeeEvaluation' could have a reference to 'EmployeeEvaluationSchema' to specify which definition the particular evaluation is based on. This can also be used to enforce the form definition in each evaluation. You would have two repositories - one for each entity. If you were to use an ORM such as NHibernate, then when you retrieve a 'EmployeeEvaluation' entity, the associated 'EmployeeEvaluationSchema' would also be retrieved even though there is a dedicated repository for it.
From your description it sounds like your objects don't have any behavior and are simple DTOs. If that is the case maybe you should not bother doing DDD. Can you imagine your entities without having getters? There are better ways to do CRUDish application than DDD. Again this is only valid if your "domain" does not have relevant behavior.