I know that deleting users in Dynamics CRM is unsupported. However, this is just a test environment that we have put up and now it needs to be 'formated'. I have managed to delete all the cases, appointments ect...
Just want to know if there is a way of deleting the users as these users have address then the address that they have is being used on a 'User Locations' dashboard, so even if I disable the users they still appear on this dashboard. Is there a way to stop that?
After a little investigation i found two ways that got around the problem of the address being displayed on the dashboard for disabled users.
Sticking to guidelines I did not DELETE the users from dynamics.
SOLUTION 1 - Good Fix
I amended the oData query that the JavaScript file used to get the data from dynamics. This then filtered the data that I was getting back from dynamics by using the isDisabled schema field name.
SOLUTION 2 - Bad Fix
I went to into each of the users that had an address and replaced the current address with the value of 'null' for each field as this is not picked up by Bing Maps when making a geoCode request.
Hope that helped if anybody reads this.
Related
We are using People API to fetch details from Directory . The API is not returning the name for most of the people in the directory. 2 accounts in our GSuite account alone provide the name field, while the others don't. However, other details like emailAddresses and phoneNumbers are available for everyone.
We didn't find any finer grained control for individual fields when using the setting External Directory Sharing → Domain and public data
We tried to change the setting from default to External Directory Sharing → Public data and authenticated user basic profile fields. However, this results in API response showing PERMISSION_DENIED error.
For one of the users in directory, we created Google Currents account. When the account was created and active, the name field became available for this user. After the account was deleted/deactivated, the name field was no longer available.
People API being used:
GET https://people.googleapis.com/v1/people:searchDirectoryPeople?query=a&sources=DIRECTORY_SOURCE_TYPE_DOMAIN_CONTACT&sources=DIRECTORY_SOURCE_TYPE_DOMAIN_PROFILE&readMask=emailAddresses,names,phoneNumbers,photos
The docs we have referred to so far are as follows:
People API - Search Directory:
https://developers.google.com/people/api/rest/v1/people/searchDirectoryPeople
Let third-party apps access Directory data:
https://support.google.com/a/answer/6343701
A merged view of people information:
https://developers.google.com/people/#a_merged_view_of_people_information
Edit:
cURL command:
curl --location --request GET 'https://people.googleapis.com/v1/people:searchDirectoryPeople?query=s&sources=DIRECTORY_SOURCE_TYPE_DOMAIN_CONTACT&sources=DIRECTORY_SOURCE_TYPE_DOMAIN_PROFILE&readMask=emailAddresses,names,phoneNumbers,photos' \
--header 'Authorization: Bearer <access-token>'
This is a known bug with the People API.
You can find it here in Google's issue tracker: https://issuetracker.google.com/issues/196235775?pli=1. If this bug is impacting you, I highly suggest you leave a comment letting the team know you're currently facing the issue and leave a +1 by clicking the "+1" button on the top right.
In the comment section of this question, it was suggested that this behavior is to be expected and is related to privacy. It's safe to say that's not the case as 1. the issue was accepted as a bug by the Google team, and 2. all other information is successfully returned from the API aside from this field.
Additional information on the resolution
Back in August of 2022, the Google team explained the fix was being held up by a bigger effort:
Hello there - apologize for the delay, we did identify the root cause,
however the fix is blocked on another bigger effort. We recently
started making progress on the blocking issue, and will provide an ETA
as soon as we figure out some of the unknowns for the solution.
However, recently (January 17th, 2023), the bug was assigned to someone at Google. This may suggest that the bigger effort was completed and that the team is now unblocked.
Potential workaround
Hopefully the bug is fixed soon. But in case we're waiting for a while, these workarounds may help.
Email is reliably returned for all directory users. The OP doesn't mention the exact context in which he or she is using the API, but for some applications you might be able to get away with using email (e.g. if you're just trying to identify the Directory user to the end user).
Additionally, if user email addresses in your directory follow a uniform formatting, you should be able to parse those to get the name. This is the workaround I'm currently using. E.g.
john.smith#example.com -> John Smith
jsmith#example.com -> J. Smith
jsmith3#example.com -> J. Smith (if you're at a large organization, you may have to remove some numbers)
Meta Sidenote
Yes, it's valid to post that something is a known bug as an answer. Check out this link if you have questions: https://meta.stackoverflow.com/a/369622/1101602.
I would like to have inside a form, the Activity panel of a related record, in particular for being able to create and modify the appointments of a lead that is related to the current record. I haven't found an out-of-the-box possibility to do this (for example a quick view form), or an external addon. But I want to try to ask: is it possible, or I need to develop a web resource, if this is worth it?
I am writing an application that accesses Dynamics 365 CE via the webapi (v9.0 / 9.1). My application retrieves a record and displays that to the user, the user can make changes and save the record again.
In that case, my application will attempt to save the changes using a Patch call against the Dynamics WebAPI.
Is there a built in way of updating only the fields that the user had changes? This is in a web application where I can't be sure to be able to have a proper client side change tracking, meaning I either have to do another call against the CRM, compare both records and send only the updated values to the CRM or send the entire record to the CRM. The second case is obviously much more performant and easier but I can't seem to find a way to tell the WebAPI to only update the changed fields..
Retrieval of record attributes using web API & binding the values to UI controls, identifying the dirty attributes & update back the source system with only those dirty fields - this is what usual cycle will be.
What you have is issue in identifying the dirty fields - it is not actual change tracking. Try to identify them in client side using an efficient way before submitting a update server request (PATCH).
Sending whole record field values irrespective of its dirtiness is not recommended for various reasons like losing Audit track, pipeline business logic in CRM Plugin/Workflow, etc.
How? Easiest method?
Tried using postman on desktop, googles OAuth2 playground and google help pages to try make sense of what to do. Ended up using GAM as this is the easiest and gives the most helpful responses.
I have tried changing this from multiple places and i always get the error:
ERROR: 400: #UserInIllegalDomain Invitation cannot be created for user in this domain - failedPrecondition
the command:
gam update course 8077159861 owner hiddenusername#longleypark.ac.uk
(username is DEFINITELY correct ive just hidden it as its not vital information)
Any help would be much appreciated, from what i can tell some guides said to add longleypark.ac.uk to whitelisted domain under classroom but because this is the primary domain for this g suite it says you cant add your current domain so this isnt an option.
I believe the google API is broken. If anyone can prove otherwise would be a great help.
Google API support haven't managed to give me any proper response, keep saying they will test and let me know but I haven't been informed of any results yet.
Google forums support has informed me once a user account is deleted and 20 days have passed the account becomes unrecoverable which means any classrooms they are the owner of become "orphans" which means "limited functionality" and the inability to change the owner ever again, the only solution is to recreate the classroom from scratch, unfortunately along with the original account all the documents submitted to that classroom are also lost.
There are NO ways around this even though the ownerId field for a classroom really should be editable from some sort of database management tool or admin console/API.
I have run into this problem today. Thought using the API I'd be able to swap the ownerId, but no.
Bizarre that Google don't let you do this as a Google Workspace admin. We know have 3 GCSE sets which are unusable with 3 months of the 2 year course left. Very frustrating.
This is a similar question to How can i get list of Domain user's from Google Apps account?
However, I'd like to use a normal account (not an administrative account) to retrieve the user list. It seems like this should be possible as the gmail autocomplete returns domain contacts not listed in the user's contact store. I've looked at the autocomplete Ajax call, but it requires something in the beginning of the string (and no, I don't really want to loop through a-z one by one - that is just way to hacky). For example:
https://mail.google.com/mail/c/u/0/data/contactstore?ac=true&ct=true&gp=true&hl=en&id=domain&max=15&out=js&tok=beginningOfUsersName&type=4
Both versions of the Google contacts API seem to omit domain users unless you have them imported into your own contacts list. I've also looked at querying users in the "Coworkers" system group, all to no avail. I also find it interesting that "add a coworker's calendar" on Google calendar does not provide autocomplete - they use a popup instead.
I'm working on a C# project, but this is a general Google API question, so any pointers in any language would help.
Update
It looks like this is feasible now with admin/directory google api endpoints
see: https://developers.google.com/admin-sdk/directory/v1/guides/manage-users?authuser=0#retrieve_users_non_admin
Original answer
I was able to work around this issue, so I'll document the workaround, even if it doesn't involve Google. I wrote a program (in C#) to query the internal Active Directory (LDAP) store and pick up all the users from there instead. At that point I could get their email addresses and query Google with it. Not the best method, but it worked for my needs.
The C# was roughly patterned from this powershell script, although I pulled out the computers query and added in the capture of the user's email address: http://www.visualbasicscript.com/List-all-users-or-computers-in-the-default-domain-m35650.aspx
The LDAP property I included to get the proper email address for Google was 'proxyAddresses', although this will not be correct for all environments.