I want to modify the view of 'Activity' entity, opened the view and try searching for edit filter criteria option and it's not available on view form.
please see below
Can you please help to advice me on how I can add filter criteria for this view above. Or how to make it visible the option 'Edit filter criteria' on the form of a view.
Any suggestion will be much appreciated. Welcome for any feedback...
I don't know any way to do that, but you can do your custom views and for example change the default view for that entity. With custom view you can change everything.
See here step by step: http://www.powerobjects.com/blog/2008/08/11/creating-and-editing-views/
What you want is impossible to achieve. Pedro's suggestion is your only option. Create your own Activity view, and then you can create your own filters. You definitely cannot create your own Associated Views. Public Views are the only ones you will have a hope of creating or modifying, and in this particular case, you are still restricted.
There are various places spread throughout CRM where you will run into problems like this, where an entity, view, or field is "locked down". This is the cost of starting with platforms like CRM which are a blackbox that only offer customization up to a certain point.
The problem in this specific case has to do with the nature of activities and the various activity types. Under the hood, there really is not a traditional record type for Activities. The Activity entity is really a "pointer entity" (note the internal name "activitypointer"). Activities really point to other entity types (in this case Activity Types) such as Email activities. The Email entity is more of a traditional entity which you can run standard queries against--but even still that is "locked down".
This additional layer of complexity makes dealing with Activities programmatically more difficult (ex. querying the data, modifying the data via a plugin/SQL, etc.) and, in this particular case, makes even the most basic customizations impossible.
Related
When creating an MVC application with a "Create" view for a particular entity and I want to relate it to another entity I could use a dynamic drop down menu.
However when the possible items is larger than 10 (for example) the drop down does not seem to offer the best user experience.
What is the recommended way to handle the input of a relationship between entities? A textbox that validates against the possible entities?
A textbox that validates against the possible entities?
That is pretty much the answer. The general idea would be to have a controller method that takes a query string and checks against the list of valid entities and returns the entities that match the query. The user can then choose from that filtered list.
You don't have to build it from scratch if you don't want to. Take a look at something like https://github.com/twitter/typeahead.js. There is also https://select2.github.io. However, there are probably lots of choices for that type of control.
I am updating a record over multiple forms/pages like a wizard. I need to save after each form to the database. However this is only a partial record. The EF POCO model has all data annotations for all the properties(Fields), so I suspect when I save this partial record I will get an error.
So I am unsure of the simplest solution to this.
Some options I have thought of:
a) Create a View Model for each form. Data Annotations on View model instead of EF Domain Model.
b) Save specific properties, rather than SaveAll, in controller for view thereby not triggering validation for non relevant properties.
c) Some other solution...??
Many thanks in Advance,
Option 1. Validation probably (especially in your case) belongs on the view model anyway. If it is technically valid (DB constraint wise) to have a partially populated record, then this is further evidence that the validation belongs on the view.
Additionally, by abstracting the validation to your view, you're allowing other consuming applications to have their own validation logic.
Additional thoughts:
I will say, though, just as a side note that it's a little awkward saving your data partially like you're doing, and unless you have a really good reason (which I originally assumed you did), you may consider holding onto that data elsewhere (session) and persisting it together at the end of the wizard.
This will allow better, more appropriate DB constraints for better data integrity. For example, if a whole record shouldn't allow a null name, then allowing nulls for the sake of breaking your commits up for the wizard may cause more long term headaches.
I'm just looking for a bit of clarity on the correct way to model custom entities and activities in CRM 2011.
I have to model a custom activity which is called a Submission. It is really just a Case with some additional properties.
When creating this in my Solution, is it best practice to base it on the Case Entity and then add the properties, or would it be better to create a new activity instead?
We have other types of activities which are similar, so I would also be basing them on the Case entity if that's the best way to go.
Many thanks,
John
I usually err on the side of creating a new custom entity (or activity), especially if you think you might have "case types" that are significantly different. It isn't fun writing a bunch of javascript that shows/hides fields based on type.
You might pick the one activity type (perhaps Submission) that is most like a "Case" and then create custom activities for the others that are close. But then you'll have subtle differences (the Customer lookup on Case, for example, can be either a Contact or Account, but you can't add your own "Customer" lookup to your custom entities).
Unless you really need something that the built-in Case entity provides that you can't do yourself, my vote would be for new entities (activities) and then just hide the built-in Case entity by security roles.
I have a web application built on an MVC design.
I have a database which contains a large number of objects (forum threads) which I can't load into memory at once. I now want to display (part of) this collection with different filters in effect (kinda like what stackoverflow does with questions sorted by date, votes, tags etc).
Where do I implement the filtering logic? It seems to me that this must go into the model part of the application, as only models interact with the database (in my implementation). If I make the filtering a part of the view, then the view must access the database directly to get the list of filtered objects, right? I'd like to avoid this, because it exposes the database layout to the view. But at the same time, displaying different views of the same data should be implemented in the view part of the application, as they are just that -- different views of the same data.
So how do I resolve this? Do I create an additional model, say, FilteredThreadsList, and have it remember the filter to use, and then use a FilteredView to display the list of threads that FilteredThreadsList spits out?
Or do I have to build a ThreadQueryier that allows views to query the database for certain thread objects, so I can have the filtering logic in a view without exposing the database backend?
You should never query data from the view. I don't know what framework you are using in particular but as for Ruby on Rails (should be the same for other frameworks) we always pull the necessary data from the controller and store all that information into a variable. The variable will be accessed by the view which can help you avoid querying your database directly from the view.If the code to query the database gets too lengthy in the controller, insert that code into the model instead so it's more maintainable for your project in the future. Additionally, you can call this model method from multiple places in your application if needed. Good luck!
From an architectural point of view, the model should be having the code for filtering. This is so, because in many applications the code for filtering is not trivial and has a good amount of domain logic in it. (Think of filtering top gainers from a list of stocks). From your example as well, it looks the same since you might want to filter by vote or by date or by tags and then by answered or unanswered etc.
In some very simple applications that deal with search/list of entities and allows Create/Read/Update/Delete of an entity, the pagination, sorting and filtering logic is usually very generic and can be implemented in a controller base class that is inherited by all entity-specific controller classes.
The bottom line is this: if your filtering logic is generic put it in the controller else put it in the model.
Model, that's only bunch of entities.
View provides a visual representation of the data from model - use as much of views as you want. If your application is web based, you can fetch data into browser just once (AJAX) using and re-use them for different UI components rendered in the browser.
As for what entities and what view to use for their representation, I think it's work of Controller. If you need some support for it on "model layer", add it but avoid tight coupling.
I've made a custom entity that will work as an data modification audit (any entity modified will trigger creating an instance of this entity). So far I have the plugin working fine (tracking old and new versions of properties changed).
I'd like to also keep track of what entity this is related to. At first I added a N:1 from DataHistory to Task (eg.) and I can indeed link back to the original task (via a "new_tasksid" attribute I added to DataHistory).
The problem is every entity I want to log will need a separate attribute id (and an additional entry in the form!)
Looking at how phone, task, etc utilize a "regardingobjectid", this is what I should do. Unfortunately, when I try to add a "dataobjectid" and map it to eg Task and PhoneCall, it complains (on the second save), that the reference needs to be unique. How does the CRM get around this and can I emulate it?
You could create your generic "dataobjectid" field, but make it a text field and store the guid of the object there. You would lose the native grids for looking at the audit records, and you wouldn't be able to join these entities through advanced find, fetch or query expressions, but if that's not important, then you can whip up an ASPX page that displays the audit logs for that record in whatever format you choose and avoid making new relationships for every entity you want to audit.
CRM has a special lookup type that can lookup to many entity types. That functionality isn't available to us customizers, unfortunately. Your best bet is to add each relationship that could be regarding and hide the lookups that aren't in use for this particular entity.