I currently have a view on the Queue entity, that includes a Category attribute for an Email, Phone Call, and Appointment:
The Category attribute in all entities is a lookup to the same Category Entity Type.
I want to be able to combine them all in a single column on the view:
The current only way I can think of, is to create a dummy Category Field on the Queue, and write a plugin to sync it with the category of the activity, or write a plugin on the retrieve multiple that hydrates the column. Are there any other possibilities? Also, the business is asking to do this in lots of different situations, so if there is a more "meta" way of handling it, that would be great to.
This is an IFD CRM if it matters.
Related
I'm using the WorkFront / AtTask API and when looking up Tasks, I'd like to filter them down to the Projects that contain specific Roles.
using /TASK/search/?fields=project:roles it will show me the Roles, but then I'm not sure how to filter on those.
Accessing a tertiary object directly (fails)
I tried /TASK/search/?project:roles:ID=aaaaaaa but the API returns (422) Unprocessable Entity.
Access from the parent object (works)
task -> project -> /PROJ/search/?roles:ID=aaaaaaa works, but involves sub-queries to the API that are costly and slow.
Access from secondary object's ID fields (works)
/TASK/search/?project:ownerID=bbbbbbb since it references a field of a secondary object and not yet another object. But I've only been able to make this work with single-instance references and don't know how to access the ID fields of collections without referencing them as objects.
So how could I filter or access down to a secondary object's collection? I can view them in a single API query, but can't seem to filter.
Task > It's Project > filter by Role
This functionality is not available in Workfront, neither through the API nor through built-in tools like Reports. This is due to a constraint on the database side of things. After seeing this question I spoke with my enterprise support team at Workfront and received confirmation of this from the DBAs.
The solution that you provided is the best you can do - split this query into the front and back half of your parameters and filter results within your code.
The best solution I can think of thus far is:
Pull the list of acceptable projects based on role.
/PROJ/search/?roles:ID=aaaaaa&...
Save the list of projects in memory
Pull the list of Tasks in question
/TASK/search/?...
Remove the tasks that don't have a project ID from step 2
This way it's only 2 queries and the project query should have a minimal impact in terms of size and number of entries.
For example i have a screen with multiple textfields (name, surname, address, phone etc) and after button click need to collect that data and pass to registration module. What is the good way to collect that data?
You can use multiple options here like
SQLite: Its pretty old way of saving and fetching data as it has lots of things to do while using.
Core Data: This is the most used way if you have multiple fields like first name, last name, email, mobile, gender, state, city, etc
Singleton Class with required fields: If you want to use properties on multiple places and with less number of initialisation, then go for with approach.
NSUserDefaults: Basically this should be used if you are saving some flags and small properties like user ID or user name.
plist (Property List): It is a flexible and convenient format for storing application data.
So as per my knowledge you can prefer Core Data as you good amount of fields and core data is easy way. And you can use same core data model for multiple entities when you want to add some more tables and fields in it.
1). Best way is to use FMDB if you want to store registration detail from textfield.
Download FMDB from Github
2). If you want to store and get only few registration data at a time then you can use NSUserDefaults for store data temporary and as well as retrieved.
I've got a lookup field on Account entity called something. Each such Something has a reference to an account. When my users click the magnifying glass, I want them to see a list of available Something records but filtered to view only such instances that link to the currently treated entity.
Also, I'll need to design such a filtration for Contact instances to only show the Something records that are related to the account that the currently regarded contact is a member of.
I can't decide between a plugin on Retrieve and some JS in OnLoad registering a fetchXML. All such operations will be done client-side. The solution needs only to work in CRM13 (and if possible apply some cool functionality in that version).
Suggestions?
JavaScript & FetchXml are your best option here as with a Retrieve plugin you're taking the performance hit of executing on every retrieve regardless of whether the entity is being retrieved for the lookup. A filtered lookup in JS only applies for those scenarios that require a change to the field on Account.
Another other good reason for using a filtered lookup in Js is they are now a supported feature in CRM 2013 as opposed to the "hack" that was required in 2011.
Some more info on addPreSearch and addCustomFilter can be found on MSDN and there's a decent blog post providing examples here.
So I'm using Core Data in an existing iPhone app, and I've set up two entities: Person and Item. The root view of my app's navigation (currently) shows a list of people, and you drill down from there to items. In short, the hierarchy looks like this:
Person -> Item
I want to add a new entity above Person in the hierarchy, called List:
List -> Person -> Item
Additionally, I want the user's first List to be created for them on startup, and for any People the user's already added to be assigned to that list.
I'm familiar with Core Data's lightweight migration & versioning feature, so I think I know how to add the new entity and relationship, but I'm not sure how to:
Create a List record on app start if they've never had the Lists feature before
Set all existing People records to belong to that new list.
One quick and dirty way would be to add some code to my app delegate's applicationDidFinishLaunching method that performs the migration by (1) checking to see if there are any Lists, (2) if not, creating the default one, (3) fetching all existing People from my data store, (4) setting each Person's list attribute to the newly created default list, and finally (5) saving those changes.
My question is: is there any faster or easier way to do all of that?
That's pretty much what you'd want to do. Use an NSFetchRequest to see if any Listss exist. If not, create one. Then do another request to get all the Persons. Here, instead of assigning the list property of each Person, I'd create an NSSet containing all your Persons and assign that to the List's people property. You did create an inverse property, right?
This is actually a pretty lightweight operation, all tolled, so I wouldn't worry too much about performance. Unless you've got hundreds or thousands of Person objects, your user will probably won't even notice.
Let's say we have "User" and a "Hotel" model classes. I'd use a User_Mapper and Hotel_Mapper to load/save/delete etc. I want to then have the user be able to mark their "favourite" hotels. In the database I have my user_favourite_hotels table which is a simple link table along with say a field for subscribing to hotel updates.
When listing out the user's favourite hotels, how would you expect this to work from an API point of view? A part of me thinks that this should be a "findFavouritesByUserId" method on the Hotel_Mapper, but other than saying it "feels" right - however a colleague suggests that the "favourites" is owned by the user and should therefore be on the User_Mapper.
Perhaps I should have a User_Hotel_Favourites_Mapper? I was thinking of incorporating the "favourites" data in to the User object so it's saved and loaded whenever the User object is. I'm not sure whether it'd be better to split it out in to it's own object and mapper however.
I'd appreciate any advice on how best to setup the API for the above and any pros/cons/experiences.
Thanks very much,
James.
This (admittedly retired) patterns&practices guide to designing data tier components suggests that you put the method in the mapper of the type of object that you're getting back from the call.
If you have methods that return a particular type of business entity, place these methods in the Data Access Logic Component for that type. For example, if you are retrieving all orders for a customer, implement that function in the Order Data Access Logic Component because your return value is of the type Order. Conversely, if you are retrieving all customers that have ordered a specific product, implement that function in the Customer Data Access Logic Component.
So, in your example, it would go in the Hotel Mapper as it is returning Hotels.
If you want to store favorite hotels for the user, you are using the UserMapper, which notices that domain object for User has changes favorites, and updates both tables for users and for user_favorite_hotels ( you just need the hotel IDs ).
When you are retrieving favorite hotels of some user, you use HotelMapper and set filter to be based on User, because you will be working with instances of Hotel.
Considering that this was asked more than 2 years ago, I'm not sure if an answer matters to you now. But here's what I think anyway.
If User could have multiple types of favourites (including Hotels), it may make sense to have a UserFavourites abstraction to cover all possible types of favourites. UserFavourites could expose a getItems() method to get the underlying Favourites.
This could be managed with the help of a manager class to return the appropriate Favourites object(FavouriteHotels for example) on which the getItems() method can be called.