Thread Details
  • State Not Answered
  • Replies 7 replies
  • Subscribers 351 subscribers
  • Views 1814 views
  • Users 0 members are here
Forum Actions
Related

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

Joana H

Hi,

When querying the /rest/v11/metadata?type_filter=modules endpoint we can see the list of fields under the /fields object.

Some fields have the property "readonly", as the name implies this defines if this field can be used on Create/Update endpoints.

Some other fields do not have the read-only property, but have a property "type" set to link, relate, another module name, etc.

On the other hand,  most of them have the source=non-db, but some of these fields are updatable.

Some others can not be used in Create/Update, the server does not throw an error, but again the values are ignored.

As far as I've seen this has to do with 1-1 or 1-* related fields/modules or calculated fields.

The question is: How can I precisely define if a field is read-only or not from the metadata? What are all the combinations of properties to make a field read-only?

Thanks!

  • 0

    To the best of my knowledge (and I am by no means an expert about metadata) the read only in the metadata definition is only for those fields that are inherently read only like calculated fields. 

    When it comes to what the user can read-write it is not controlled in the API itself but by the ACLs, the user's Role dictates whether they have access to that field and in what capacity.

    There is very little control in the APIs themselves and you need to be very careful to enforce the quality of your data in the construction of the API's payload itself.

    There is, for example, no check inside the API that an enum value is valid, or that dependencies are enforced, those are all enforced by the user interface, not the underlying APIs.

    Does this answer your question?

    FrancescaS

    PS. you can find more information about the data framework Sugar uses here, though perhaps not in as much detail as you are looking for:

    support.sugarcrm.com/.../

  • 0

    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.

  • 0 in reply to Joana H

    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

  • 0 in reply to Francesca Shiekh

    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?

  • 0 in reply to Joana H

    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/

  • 0

    Hi  do you have any other idea from a developer's point of view?

  • 0 Sugar Employee Badge in reply to Joana H

      ,

    I gathered few smart engineers here to answer your question so here it is:
    It's not easily determined from metadata alone because there are several ways it can hit a readonly condition:
    1. Field is defined as 'readonly' => true ,
    2. Field is defined as 'calculated' => true as Sid noted, but only if 'enforced' => false is not also set
    3. Field is defined as conditionally readonly based on a SugarLogic formula, for example: 'readonly_formula' => 'not(equal($id,""))',
    4. There are Role restrictions not available through metadata
    5. There may be JS code in a particular view that make the field readonly at runtime
    Perhaps if you share your use case with all of us, we could come up with a suggestion.

    SugarCRM | Principal Developer Advocate