I'm using SuiteCRM 7.5.3. People with knowledge of SugarCRM CE up to version 6.5 are also welcome to answer, as the answers should apply to both systems.
I'm trying to do some data modelling, fitting my data to the Sugar/Suite concepts.
What I know about the "Direct Reports" relationship: it's a one-to-many relationship linking two Contacts.
This means that a certain contact can have many people who are his "direct reports", but each person can only report directly to a single manager.
What I don't know, and would like to ask: are there any other less apparent semantics taking effect, or does SuiteCRM simply record the relationship, display it, and do nothing more about it?
Things like: the manager being able to access certain records of his direct reports; or notifications to the manager of things happening to the direct reports; or any change in the logic of record assignment, etc.
Anything will be useful to know, even if it only a partial answer.
I'm a bit late in answering this, so don't know whether it will be helpful or not. I'm an open source developer and freelancer who is studying the SuiteCRM architecture, so I'll answer your question from that perspective.
What I know about the "Direct Reports" relationship: it's a one-to-many relationship linking two Contacts.
Yes, its a one-to-many, meaning one manager can have multiple subordinates, but not vice-versa. In the database, however, they are not maintained as separate tables of employee and subordinates, its just a single contacts table with a single field called reports_to_id:
desc contacts;
...
| assistant
| assistant_phone
| lead_source
| **reports_to_id**
| birthdate
...
From reports_to_id field, the system knows that who is the line manager of this current contact/employee and displays on the contacts screen accordingly. So yeah, presently it just seems like it is only used to map a contact with their subordinates for display. If this field is having any repercussions anywhere else in the system, then I don't know about it yet.
Hope this helps.
Related
I am working on a react-native app using nodejs and mongodb on the backend. In my app users are able to create multiple accounts and there are different account types (Business, Artist, Venue, etc.). For the most part, each account type has the same data and fields in the database. Things like name, location, website. But it is possible for each account type to have a couple pieces of data specific to that account. My question is, should I simply have one "Account" collection in the database that stores all accounts and has an "accountType" field to differentiate each account?
Initially I thought to do the opposite and store each account type in a separate collection, but I found it made the client code pretty messy as I found myself adding a bunch of if statements to determine things like what api endpoint to make requests to, what components to render, and what screens to navigate to, when in reality, it's really just a couple pieces of data that may change from one account type to another.
It seems like having just one "Accounts" collection with an "accountType" field will greatly simplify the code. But maybe there is something I am missing. If anyone has some insight as to which approach may be better for the situation, or some of the pros/cons of each approach, I'd really appreciate the help! Thanks!
Well, the answer clearly depends on how the documents for different types of accounts differ. But, the idea of going with a single collection is fine, also take a look at the Subset Pattern, it's will give you a fine idea, of how to divide data into different collections, depending on their usage.
Basically, I'm querying the D365 web API and I'm trying to get all of the related contacts for an account.
Been following this link:
https://learn.microsoft.com/en-us/dynamics365/customer-engagement/developer/webapi/query-data-web-api#retrieve-related-entities-by-expanding-navigation-properties
Trying to use $expand but it only will bring over _primarycontactid_value. So just the one primary contact and not everyone that is related to the Account.
It would look something like the following:
/api/data/v9.0/accounts&?select=name&$expand=Contacts(fullname, email)
The only fields in Account that have "contact" in them are:
preferredcontactmethodcode
_primarycontactid_value
address2_primarycontactname
address1_primarycontactname
_tcc_primaryinvoicecontactid_value
_tcc_consultingcontact_value
_tcc_contactlist_value //some custom field that doesn't apparently do anything
_new_foundationcontact_value
_tcc_primaryapcontactid_value
So none of which can be used to look-up all of the contacts... that I know of.
Another way to do it would be to start with the Contact first and then $expand= on the _parentcustomerid_value. But I need to filter on the Account to specify certain accounts that I want... this would just bring over every account and be incredibly slow. I'm not sure there is a way to $filter= on an $expand= value.
So:
How can I query the Account and all the related to Contacts for an Account?
If there is no way, is it possible to use $filter= on and $expand= value?
Trying to keep the amount of queries to a minimum. This could be solved by doing multiple iterative queries, but that will just make it incredibly slow. Or just query everything and piece it together, but that will be slow as well.
Ok, stumbled across the answer: contact_customer_accounts.
Query ends up looking like the following: /api/data/v9.0/accounts&?select=name&$expand=contact_customer_accounts($select=fullname).
As far as I can tell, custom relationships can be used as well, although I have only tested with 1:N types.
Still takes a little while to generate, but works.
I'm trying to understand this from a REST theoretical perspective.
You have a book collection, it's an entity you can get, delete, etc.
You have an individual book, you get it with an id, delete it with an id, etc
You have an Angular app where you can add new books. So you get the book collection, add a book locally, haven't sent it to the server yet
You need additional info on the book before you add it, for example you need to know if there are any other books with the same title
Can you have multiple GET calls in a RESTful architecture for the same entity? i.e. one with id and another with a name? So you could try to GET the book with the name to see if it already exists
Where does 'get additional info for an as of yet uncreated entity' fit into this? Lets say you need an image for the book and you have stock images, I'm assuming that the images are entities in and of themselves so they have their own REST APIs
If I understand your question correctly, you basically want to do a search on some criteria (name, etc) to check that the book does not already exist. You can use GET for book which would not include id as a path variable but would include the criteria filter params as request parameters(query string). Something like this:
/book?name=bookname -- List book with name as bookname
/book/{id} -- List book with given id
Multiple GET calls for the same entity is not encouraged in a RESTful architecture.
Can you have multiple GET calls in a RESTful architecture for the same entity?
Jim Webber: You should expect to have many many more resources in your integration domain than you do business objects in your business domain.
So sure, why not? How could the client possibly know?
Where does 'get additional info for an as of yet uncreated entity' fit into this?
When in doubt, try to envision what you are doing as a web page. Would be be reasonable to send to ask the web server for a form to add a new book with a particular title, and have it return the form, a list of known books with similar titles, a set of stock images, etc? Of course. So it's going to be fine for your API to do the same thing.
Or perhaps the form should be a separate idea, and the search results should look like a link to the form, and a bunch of links to representations of existing books. That's also fine.
Using links from unstable things to stable things is often a good idea, because it affords caching.
In reference to a previous question of mine:
qbfc CustomerQuery based on email address?
Is it possible to create a custom detail report of customers, and using a custom field to "filter" the report. I must admit, I am not really clued in on CustomDetailReports, as I have no need for implementing them, and never had.
It does however look like its supposed to do just what it says, a custom report feeding you info form quickbooks?
What I am attempting to do, is get a list of customers in a detailed report, and filtering that report based on a custom field value. This way I can narrow down my possibilities of customers I need to check for, and get their ListID's or FullNames.
Currently I am returning all the customers using a customerquery, and iterating through them one by one to get the guy I am looking for. This is becoming a slow process as the customers increase.
I can store my own reference in an external DB, and use that to reference an email address to a customer ListID, but I would really like to achieve this with the data stored in Quickbooks only, as per the Quickbooks philosophy of, "Store Data Once"
Before I spend resources on trying to implement a custom report, can something like the above be achieved with Custom Detail Reports?
Thanks in advance.
Is it possible to create a custom detail report of customers, and using a custom field to "filter" the report.
Nope. QuickBooks does not support this.
It does however look like its supposed to do just what it says, a custom report feeding you info form quickbooks?
It will display a custom report, yes... but it won't allow you to filter it by custom fields.
Currently I am returning all the customers using a customerquery, and iterating through them one by one to get the guy I am looking for. This is becoming a slow process as the customers increase.
Have you considered instead caching the customers in your app? That would be much faster. Then you can just periodically run a query against QuickBooks to get customers that have been updated since the last time you ran the query (e.g. incremental sync of data).
I can store my own reference in an external DB, and use that to reference an email address to a customer ListID, but I would really like to achieve this with the data stored in Quickbooks only, as per the Quickbooks philosophy of, "Store Data Once"
My personal experience has been that, unfortunately, the query syntax that QuickBooks allows/uses is too restrictive for that to be realistic.
I keep on finding myself wanting to add fields to CRM forms that don't actually represent physical fields on the entity. I want these fields to be sent in the Update message, for the benefit of my Plugins...
For example, imagine something like the out-of-the-box contact/address functionality. The main contact address is exposed as a set of fields on the Contact form. However, in actual fact there is some magic going on behind the scenes that causes an Address record to be created for the Contact containing the address details. I don't actually want to reproduce this, but it's a fair example...
Now, I know how to write a plugin that takes the address fields entered in the Create/Update message, and actually writes them into an Address object instead. That is simple enough. It seems the hard part is convincing CRM to display fields on the form for the user to enter the address data.
The only way I can see to do this is to create "fake" fields in the Contact-equivilent form, so that the form editor allows me to add the fields to the dialog. Then I have to filter these attributes out in a plugin, so the fake fields don't actually get written to the DB.
This would work, but involves filling the DB schema with fake columns that will (or should) never have any data in them. This makes future cusomisation of the system more confusing, as there are decoy fields called "DON'T USE - Address1" knocking around in all the GUIs. The problem gets worse when I need a fake Lookup field - this involves creating a fake relationship.
So: Is there a way to achieve the same thing without dumping fake garbage in the database schema?
Is there, perhaps, some way to create a form field for an arbitary attribute in Javascript on the form, such that the Attributes will be included in an Update message?
Sure, I realise I could IFrame or Silverlight something up to cater for this, but I'd rather use the genuine CRM form fields, and handle the data in the Update/Create message plugin hook.
Unfortunately, you have already mentioned the two options that I can think of: fake fields or custom IFrames.
I know it feels "dirty" but I actually haven't had much trouble doing the fake fields thing. Standardized naming conventions are your friend. I prefer fake fields over IFrames because users can still query and filter them in Advanced Find, reports, views, etc.
Just make sure they are readonly and make sure your plugins don't swallow exceptions - you want exceptions to bubble up and cancel the transaction instead of the possibility of the main record getting updated without the children.