Announcement

Collapse
No announcement yet.

General error (2000) when querying RecIDs using field 'FLDWRKUSERNAME'

Collapse
X
 
  • Filter
  • Time
Clear All
new posts

    General error (2000) when querying RecIDs using field 'FLDWRKUSERNAME'

    I'm using Commit's low level API.

    I found this field inside of Commit with Accounts > Tools > Field Management, then on the Fields List drop down box I selected User Details, I picked Username in the list, and clicked the field settings box below.

    When I attempt to query employee record IDs using 'FLDWRKUSERNAME', Commit returns error code 2000, which helpfully indicates 'General Error Occurred'. In my experience, this error is usually returned when that field doesn't exist. I'm wondering if I might be using the wrong data type, based on the different prefix on the field name. (FLDWRK vs. FLDCRD)

    Here's an example of the query:

    <?xml version="1.0" ?>
    <?commitcrmxmlqueryrequest version="1.0" ?>
    <CommitCRMQueryDataRequest>
    <ExternalApplicationName>CommitAgent</ExternalApplicationName>
    <Datakind>ACCOUNT</Datakind>
    <MaxRecordCount>255</MaxRecordCount>
    <Query>
    <Where>
    <FLDWRKUSERNAME op="=">jkogut</FLDWRKUSERNAME>
    </Where>
    <Order/>
    </Query>
    </CommitCRMQueryDataRequest>
    (I tried formatting the XML, but it seems the indent tag does nothing.)

    The user exists with that username, and other queries work, for instance, using field 'FLDCRDCONTACT'. This one, however, does not.

    What am I doing wrong?

    Re: General error (2000) when querying RecIDs using field 'FLDWRKUSERNAME'

    Thanks for asking. It seems that you're trying to query about user Accounts and the only way to do that is to query by their employee account record ID. Do note, that user related fields will not be accessible (such as user credentials fields, etc.). You will be able to query all of the contact record account from name to address to phone to any of the Account customer fields. In other words, you should treat and consider them as Accounts and query everything about their account record, but you cannot query by or query any data related to them being users. This is related to security of the system and this is why it isn't supported. Thanks!

    Comment


      Re: General error (2000) when querying RecIDs using field 'FLDWRKUSERNAME'

      Thanks for the response.

      The reason I'm querying the database for the username is because I have an application I'm writing to automatically generate assets and ticket history notes, and history notes require an employee ID. I'd like the automatically generated notes to be entered under the user that started the program, instead of a generic admin account, which means I need that user's ID.

      In order to get the employee ID, I'm having the user enter their username when the application is started, and with a single query, I was hoping to get the employee ID.

      I'm working around it right now by simply querying the employee contact field, and since all of our employees' usernames consist of their first initial and last name, I can generate the username accordingly.

      This isn't an ideal solution. If we ever have an employee with a username that breaks this pattern, the application will not work.

      EDIT: While I'm at it, it would be nice to also have an authentication function to pass a user's username and password, and have it return a boolean indicating if they were authenticated or not.

      Comment


        Re: General error (2000) when querying RecIDs using field 'FLDWRKUSERNAME'

        What you may do is store the users RangerMSP's RECID in your application and use it. This will prevent any future issues. Yes, when a new user is created you need to paste it to the dedicated field in your app but then it's done, safe and it won't break if the staff name, contact or anything else is being modified by someone using RangerMSP.

        Checking authentications with booloean result makes it super easy to use rainbow tables, loop and get to the user password. I doubt that we will allow this but will take a note of this anyhow. Thanks.

        Comment

        Working...
        X