Our application needs to validate the field-level security of Product/Product Code in Opportunity Product. As there are no Product(Product2Id) and Product Code(ProductCode) fields in Opportunity Product(OpportunityLineItem), I think we might need to go through PricebookEntry to validate them. However, I tried to turn Product Code Visible off, I can still query the ProductCode through PricebookEntry from OpportunityLineItem.

I was wondering how to validate them. Thanks for any help.

My understanding is that we can use Field.isUpdateable() to validate if a field is Read-Only in Field-Level Security Page. However, when I turn some field's Read-Only on, isUpdateable() still returned TRUE. Did I do anything wrong?

Thanks for help.

We validate the object permissions by using describeSObject, but how can they associate to a profile? The same question for the field level security -- how the field level security associate to a profile?

Thanks for any of help.  

Message Edited by cw on 07-18-2005 09:38 AM

The page of Field-Level Security for profile shows if fields are visible. My question is how we validate this field's visibility. API has isCreatable(), isFilterable(), isNillable() and isUpdateable() for Field.

Thanks for any of help.

Hello,

One can get the field accessibility information through the API for the caller by doing a describe.  Is there some way of getting the field accessibility information directly for a profile?  I need field accessibility information for a user other than the caller.

Regards,

Len Takeuchi

Salescentrix.com

Hello,

We are using WILs to integrate with a hosted product.  Every WIL invocation to our site winds up starting a new http session on our side, which is not desirable since we want to maintain some information across WIL invocations.  Is there a way to allow a WIL invocation to pick up an existing http session on our site?  If this is not possible we would have to store the information using salesforce session id as the key in a mechanism separate from the http session.

Regards,

Len Takeuchi

Salescentrix.com

Hi,

There doesn't seem to be any access control to prevent a user from updating his/her own user information (other than assigning profile which is controlled by Manage User permission).  There is no page layout or field level security for "My Personal Information".  We are adding a few custom fields on User which we would either like to be read-only or not visible in "My Personal Information" but visible and editable when managing Users (i.e. a user with Manage User permission is managing users).   Is there a way to do this that I'm missing?  If not, is there going to some kind of access control to User Information in the very near future?

Regards,

Len Takeuchi

Salescentrix.com

Hi,

I'm expecting the answer to be "no", but is there any easy way to get all the Accounts in the hierarchy that an Account belongs to?  I'm trying to avoid doing the brute force approach of retrieving the Account and then making successive queries to retrieve other Accounts that are related to it up, down, and sideways in the tree -- This is quite inefficient.

Hi,

Is it likely that a future version of the API would provide a call to determine if a particular object instance is editable and deletable -- Perhaps if the base SObject class had an "updateable" and a "deletable" element whose values would indicate, respectively, if the caller is able to update and delete a particular object instance that it has retrieved?  These elements would be similar to the "updateable" and "deletable" elements that are returned in the DescribeSObjectResult, but different in 2 ways: (1) they are at the instance level rather than the class level; and (2) they are based on the organization-wide sharing that is in effect and also possibly whatever AccountShares and OpportunityShares that have been defined.  What I'm trying to do is to answer the question "Can I update/delete this Account that I've retrieved?" so that I can consistently enforce constraints on custom objects that are linked to the Account -- e.g., if the caller can't update a particular Account I don't want him to be able to update a custom object instance that is linked to that Account, either.

Theoretically it is already currently possible for us to determine this information, but it requires explicitly making numerous calls to get the current settings for the organization-wide defaults as well as querying AccountShares and OpportunityShares and perhaps even Roles and Groups/GroupMembers.  It would be a lot nicer if the API could provide a call (or to return the information as part of each returned SObject instance if requested) rather than us having to essentially re-implement SFDC's sharing model/rules in order to manually determine these answers.

Thanks in advance.

Currently through the 2.5 API we have no explicitly control over transaction scope â¬? Although the create, update, and delete calls do allow more than one object of the same type to be involved, each of the objects is handled in a separate transaction.  Will we have greater control over transaction scope in future versions of the API â¬? e.g., Will there at least be a new API call available that would take an array of objects of different types to be created and/or updated and/or deleted within a single transaction?

For example, if I want to update an Account which has a custom field for the outstanding balance and at the same time create a payment (where Payment is a custom object) as well as create several other custom objects relating to Accounts Receivable, will I be able to make all the necessary changes within a single transaction?  Not being able to perform multiple operations in a single transaction can result in inconsistent data â¬? Inconsistent data is something we really cannot afford to have, especially in an application like ours that deals with Accounting information.

We are currently investigating how to integrate our application with salesforce.com.  One thing we will likely need to do is to extend the Account object with additional information, probably using custom fields.  In addition to extending the Account object we also want to add some of our own objects â¬? These additional objects logically have Account as the parent object.  We have not yet decided if we want to keep these additional objects in our own database (i.e., managed by our own web application) or if we would use custom objects and thus keep the data inside salesforce.com.  Regardless of the approach we take however, we need to ensure the integrity of these additional objects.

Specifically, letâ¬?s consider the case of maintaining referential integrity.  With some objects it makes sense to do cascading deletion when the parent Account is deleted, but for other objects it makes better sense to prevent the parent Account from being deleted.  My question is in two parts:  (a) what is the best way to accomplish this today; and (b) are there any new features being added to sforce (either in the next release or at least on the roadmap) that might make it easier to accomplish such a task in the near future?

A couple of features that I can see as being useful for managing data integrity would be:

(1) The ability to define custom objects that have a custom reference to a parent object and additionally the ability to specify whether the child object should be deleted through cascading deletion or whether the deletion of the parent should fail if it has a related child object.

(2) The ability to implement custom â¬?createâ¬?, â¬?updateâ¬?, and â¬?deleteâ¬? operations for objects by POSTing to an external URL rather than having the request directly handled by salesforce.com.  This would provide a way for an external application to execute custom business logic before doing the actual object creation, update, or deletion via the sforce API.  There could be situations where the external application might decide to fail the operation.  In the case of an object being created or updated, the external application might need to implement additional validation for custom fields or it may need to enforce additional constraints between objects.

Thanks in advance.

Hi,

Is it likely that a future version of the API would provide a call to determine if a particular object instance is editable and deletable -- Perhaps if the base SObject class had an "updateable" and a "deletable" element whose values would indicate, respectively, if the caller is able to update and delete a particular object instance that it has retrieved?  These elements would be similar to the "updateable" and "deletable" elements that are returned in the DescribeSObjectResult, but different in 2 ways: (1) they are at the instance level rather than the class level; and (2) they are based on the organization-wide sharing that is in effect and also possibly whatever AccountShares and OpportunityShares that have been defined.  What I'm trying to do is to answer the question "Can I update/delete this Account that I've retrieved?" so that I can consistently enforce constraints on custom objects that are linked to the Account -- e.g., if the caller can't update a particular Account I don't want him to be able to update a custom object instance that is linked to that Account, either.

Theoretically it is already currently possible for us to determine this information, but it requires explicitly making numerous calls to get the current settings for the organization-wide defaults as well as querying AccountShares and OpportunityShares and perhaps even Roles and Groups/GroupMembers.  It would be a lot nicer if the API could provide a call (or to return the information as part of each returned SObject instance if requested) rather than us having to essentially re-implement SFDC's sharing model/rules in order to manually determine these answers.

Thanks in advance.

Our application needs to validate the field-level security of Product/Product Code in Opportunity Product. As there are no Product(Product2Id) and Product Code(ProductCode) fields in Opportunity Product(OpportunityLineItem), I think we might need to go through PricebookEntry to validate them. However, I tried to turn Product Code Visible off, I can still query the ProductCode through PricebookEntry from OpportunityLineItem.

I was wondering how to validate them. Thanks for any help.

We validate the object permissions by using describeSObject, but how can they associate to a profile? The same question for the field level security -- how the field level security associate to a profile?

Thanks for any of help.  

Message Edited by cw on 07-18-2005 09:38 AM

The page of Field-Level Security for profile shows if fields are visible. My question is how we validate this field's visibility. API has isCreatable(), isFilterable(), isNillable() and isUpdateable() for Field.

Thanks for any of help.

I like to make Sforce application with Grand Central Communications
framework. Sforce is in the service directory but I cannot get the WSDL.

Message Edited by expeditebiz on 11-30-2004 03:02 PM

Hi,

     I need a control which will query the sforce database and I need to perform database updation also. Since Iam not comfortable with Java Iam planning to do it in Javascript.

Will it possible to use SFORCE OBJECT QUERY LANGUAGE (SOQL) in  in Javascript?

Does anyone know of any examples/Sample code   for creating SControl s in Javascript which uses API to update the database?

I appreciate any help in getting me started

das

To query using the updated or deleted scope it says you need to have "replicate: access to the entity type.  How do you enable the Database Replication feature? Is it possible to do so under the developer edition?  Is it possible to do so through the API?

-Pawan