SugarCRM API Metadata endpoint. Properties - How to define an updatable field?

Thanks for the feedback. Yes, the user ACL is one point.

Let's say we have an admin user that has all the required access to all CRUD operations.

What happens is that this user cannot update the properties of a child object.

For instance:

module name: SugarFavorites

Not allowed update on: Account_Name

Allowed update on Account_id (this will update the Account_name under the hood since it's a foreign key)

This looks like a DB constraint depending on the data model/schema. I'd like to know based on what metadata properties combination I can throw an error to my users when trying to update/insert those fields.

SugarFavorites does not have an Account_name/Account_id

aside from that, I don't think you can tell from the metadata what the DB-level constraints may be.

Francesca

Then how can we define if a field is a base field of that module and not a foreign key or a field of a child?

Why doesn't the server throw errors when trying to insert read-only properties?

Properties such as "required", field dependencies, and field validations, are functions of the front end.
The APIs do not respect any of those.
It is up to the developer of the application that calls the SugarAPI to make sure that the validation is done before the payload is added to the API call.

Similarly you need to know the difference between relationships and relate field to correctly create links between different entities. For relate fields you can simply add the id of the parent in the FK field, but for relationships you need a separate API call once both ends of the relationship have been saved and have an ID.

In other words, you need to know your particular instance of Sugar very well to work with APIs, you need to know what checks and balances to enforce before the API is even called and you need to know how back end information like "link" names to add relationships.

It is one reason I suggested limiting user access to APIs, you can do quite a bit of damage to your data if you don't know what you are doing when calling an API.
portal.sugarondemand.com/

Properties such as "required", field dependencies, and field validations, are functions of the front end.
The APIs do not respect any of those.
It is up to the developer of the application that calls the SugarAPI to make sure that the validation is done before the payload is added to the API call.

Similarly you need to know the difference between relationships and relate field to correctly create links between different entities. For relate fields you can simply add the id of the parent in the FK field, but for relationships you need a separate API call once both ends of the relationship have been saved and have an ID.

In other words, you need to know your particular instance of Sugar very well to work with APIs, you need to know what checks and balances to enforce before the API is even called and you need to know how back end information like "link" names to add relationships.

It is one reason I suggested limiting user access to APIs, you can do quite a bit of damage to your data if you don't know what you are doing when calling an API.
portal.sugarondemand.com/