There are no new updates to share this week. Please see below for a recap of published announcements.
Previous announcements
The announcements below were published on the Workspace Updates blog earlier this week. Please refer to the original blog posts for complete details.
Migrate your classic Google Sites before December 1, 2022
We’re extending the previously announced timeline to give Google Workspace customers more time to migrate from classic Google Sites to new Google Sites:
Starting December 1, 2022 (previously June 1, 2022), you will no longer be able to edit any remaining classic Sites in your domain.
Starting January 1, 2023 (previously July 1, 2022), Classic Sites will no longer be viewable unless they are converted to new Google Sites.
New and updated third-party DevOps integrations for Google Chat, including PagerDuty
There are now a variety of additional DevOps integrations that allow you to act on common workflows directly in Google Chat. | Learn more.
Export log data in near-real time to BigQuery
Exported log data streams are now in near-real time (under 10 minutes), improving upon the previous process which returned log data that could be up to three days old. | Learn more here and here.
AppSheet Enterprise Standard and Enterprise Plus available as add-ons to Google Workspace editions
Google Workspace customers can now purchase AppSheet Enterprise Standard and Enterprise Plus as add-ons by contacting their Google Cloud sales representative or through the Google Workspace Partner network. | Learn more.
Use Connected Sheets with VPC-SC protected data, improved Cloud Audit Logs for Connected Sheets events
New banners in Google Chat protect against malicious links
In Google Chat, you can now see banners warning against potential phishing and malware messages coming from users with personal Google Accounts to help protect users against malicious actors, keeping data safe. | Learn more.
In our ongoing Serverless Migration Station series aimed at helping developers modernize their serverless applications, one of the key objectives for Google App Engine developers is to upgrade to the latest language runtimes, such as from Python 2 to 3 or Java 8 to 17. Another objective is to help developers learn how to move away from App Engine legacy APIs (now called "bundled services") to Cloud standalone equivalent services. Once this has been accomplished, apps are much more portable, making them flexible enough to:
In today's Module 12 video, we're going to start our journey by implementing App Engine's Memcache bundled service, setting us up for our next move to a more complete in-cloud caching service, Cloud Memorystore. Most apps typically rely on some database, and in many situations, they can benefit from a caching layer to reduce the number of queries and improve response latency. In the video, we add use of Memcache to a Python 2 app that has already migrated web frameworks from webapp2 to Flask, providing greater portability and execution options. More importantly, it paves the way for an eventual 3.x upgrade because the Python 3 App Engine runtime does not support webapp2. We'll cover both the 3.x and Cloud Memorystore ports next in Module 13.
Got an older app needing an update? We can help with that.
Adding use of Memcache
The sample application registers individual web page "visits," storing visitor information such as the IP address and user agent. In the original app, these values are stored immediately, and then the most recent visits are queried to display in the browser. If the same user continuously refreshes their browser, each refresh constitutes a new visit. To discourage this type of abuse, we cache the same user's visit for an hour, returning the same cached list of most recent visits unless a new visitor arrives or an hour has elapsed since their initial visit.
Below is pseudocode representing the core part of the app that saves new visits and queries for the most recent visits. Before, you can see how each visit is registered. After the update, the app attempts to fetch these visits from the cache. If cached results are available and "fresh" (within the hour), they're used immediately, but if cache is empty, or a new visitor arrives, the current visit is stored as before, and this latest collection of visits is cached for an hour. The bolded lines represent the new code that manages the cached data.
Adding App Engine Memcache usage to sample app
Wrap-up
Today's "migration" began with the Module 1 sample app. We added a Memcache-based caching layer and arrived at the finish line with the Module 12 sample app. To practice this on your own, follow the codelab doing it by-hand while following the video. The Module 12 app will then be ready to upgrade to Cloud Memorystore should you choose to do so.
If you do want to move to Cloud Memorystore, stay tuned for the Module 13 video or try its codelab to get a sneak peek. All Serverless Migration Station content (codelabs, videos, source code [when available]) can be accessed at its open source repo. While our content initially focuses on Python users, we hope to one day cover other language runtimes, so stay tuned. For additional video content, check out our broader Serverless Expeditions series.
Google Workspace administrators can also use the API controls in Admin Console if they would also like to restrict access to Google Chat data.
Who’s impacted
Admins and Developers
Why you’d use it
While it’s easy to create new Spaces and add members directly in Google Chat, there are cases where Spaces can be filled with many topics and side conversations, making it difficult to keep track of important information. Using the new API functionality, you can set up new spaces that focus on a specific topic, team, or project. For example, an on-call app can automatically create a space when an outage has been detected.
We’re improving search rankings in Cloud Search by taking into account document popularity. This means documents that have been clicked on by a large number of users will be prioritized in the overall search rankings. By surfacing popular and useful documents that match a user’s query, this will help reduce the effort and time required to find relevant documents.
Getting started
Admins: The feature is available by default. Use this guide to learn more about the use of Document Popularity in Cloud Search ranking. Note: You need to use the default redirect URLs for search results when using Cloud Search Query API for this feature to work.
Available to Google Workspace Business Plus, Enterprise Standard, Enterprise Plus, and Education Plus customers
Not available to Google Workspace Essentials, Business Starter, Business Standard, Enterprise Essentials, Education Fundamentals, Frontline, and Nonprofits, as well as G Suite Basic and Business customers
Google Workspace developers can now create Google Workspace add-ons that attach files to a Google Calendar event from any third-party service. This feature enables developers to create add-ons that support attachments from a wide range of sources beyond Google Drive, such as digital whiteboard, content creation, or file management tools.
Users who have the relevant add-ons installed will be able to attach files from these sources to a Calendar event, and attendees can view the event with the attachment on the web or on mobile.
Attach files from a third-party service to a Calendar event
After attaching files in Calendar on the web, users can view the event with the attachment on the web or on mobile.
End users: If allowed by your admin, you’ll be able to install a Calendar add-on using the “+” button in the quick access side panel or via the Google Workspace Marketplace. End users need to install a compatible add-on to enable this feature.
Rollout pace
This feature is available now for all developers and users.
Availability
Available to all Google Workspace customers, as well as legacy G Suite Basic and Business customers
The Google Forms API provides programmatic access for managing Google Forms and acting on responses— empowering developers to build powerful integrations on top of Forms.
Who’s impacted
Admins and developers
Why you’d use it
The Google Forms API provides programmatic access to manage Forms and receive responses, supporting the development of a variety of powerful integrations. For example, you can use the API to develop real-time dashboards or data visualizations; trigger business workflows incorporating project management, CRM, or LMS tools; or auto-generate forms from question banks or other data sets.
The API is useful for a variety of tasks such as:
Creating and modifying forms or quizzes
Retrieving form responses or quiz grades
Reading form content and metadata
Receiving push notifications for form or quiz responses or form structure updates
At Google Cloud Next 2021, we announced the Google Forms API Beta, which provides programmatic access for managing Google Forms and acting on responses— empowering developers to build powerful integrations on top of Forms.
The Google Forms API is now rolling out as an Open Beta which means developers who are part of our Early Adopter Program can make their integrations available to the public. We’ll no longer require individual end-user accounts to be allowlisted. Developers should keep in mind, however, that their integrations are in Beta.
Developers can apply to join our Early Adopter Program and begin developing using the Google Forms API by filling out this form.
See below for more information.
Who’s impacted
Admins and developers
Why you’d use it
The Google Forms API provides programmatic access to manage Forms and receive responses, supporting the development of a variety of powerful integrations. For example, the API could be utilized to develop real-time dashboards or data visualizations, trigger business workflows incorporating project management, CRM, or LMS tools, or auto-generate forms from question banks or other data sets.
The API is useful for a variety of tasks such as:
Creating and modifying forms or quizzes
Retrieving form responses or quiz grades
Reading form content and metadata
Receiving push notifications for form or quiz responses and updates
We’re now expanding the beta to include desktop data for Google Meet and Google Drive. Additionally, key access service APIs are now publicly available for anyone to use.
Encryption notice in Meet
Lastly, we are adding two new Key access service partners (Fortanix, Stormshield) for customers looking for a dedicated partner that integrates with the key access service APIs. Previously, we had announced key service partnerships with Flowcrypt, FutureX, Thales and Virtru.
The beta is available to Google Workspace Enterprise Plus and Google Workspace Education Plus customers—eligible customers can now apply for the beta here. Important note: Customers who are already participating in the beta will have to reapply for access to the Google Meet and functionality, but you will be able to reuse your key service configuration.
Who’s impacted
Admins and developers
Why it’s important
Google Workspace already uses the latest cryptographic standards to encrypt all data at rest and in transit between our facilities. With Client-side encryption, we’re taking this a step further by giving customers direct control of encryption keys and the identity provider used to access those keys. This can help you strengthen the confidentiality of your data while helping to address a broad range of data sovereignty and compliance needs.
When using Client-side encryption, customer data is indecipherable to Google. Customers can create a fundamentally stronger privacy posture to comply with regulations like ITAR and CJIS or simply to better protect the privacy of their confidential data
If you are looking to choose a key service access partner, Flowcrypt, Fortanix, Futurex, Stormshield, Thales, and Virtru have built tools in accordance with Google’s specifications and provide both key management and access control capabilities. Your partner of choice holds the key to decode encrypted Google Workspace files, and Google cannot access or decipher these files without this key.
Available to Enterprise Plus and Education Plus customers
Not available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Enterprise Standard, Education Fundamentals, Frontline, and Nonprofits, as well as G Suite Basic and Business customers.
The previous Module 7 episode of Serverless Migration Station gave developers an idea of how App Engine push tasks work and how to implement their use in an existing App Engine ndb Flask app. In this Module 8 episode, we migrate this app from the App Engine Datastore (ndb) and Task Queue (taskqueue) APIs to Cloud NDB and Cloud Tasks. This makes your app more portable and provides a smoother transition from Python 2 to 3. The same principle applies to upgrading other legacy App Engine apps from Java 8 to 11, PHP 5 to 7, and up to Go 1.12 or newer.
Over the years, many of the original App Engine services such as Datastore, Memcache, and Blobstore, have matured to become their own standalone products, for example, Cloud Datastore, Cloud Memorystore, and Cloud Storage, respectively. The same is true for App Engine Task Queues, whose functionality has been split out to Cloud Tasks (push queues) and Cloud Pub/Sub (pull queues), now accessible to developers and applications outside of App Engine.
Migrating App Engine push queues to Cloud Tasks video
Migrating to Cloud NDB and Cloud Tasks
The key updates being made to the application:
Add support for Google Cloud client libraries in the app's configuration
Switch from App Engine APIs to their standalone Cloud equivalents
Make required library adjustments, e.g., add use of Cloud NDB context manager
Complete additional setup for Cloud Tasks
Make minor updates to the task handler itself
The bulk of the updates are in #3 and #4 above, and those are reflected in the following "diff"s for the main application file:
Primary differences switching to Cloud NDB & Cloud Tasks
With these changes implemented, the web app works identically to that of the Module 7 sample, but both the database and task queue functionality have been completely swapped to using the standalone/unbundled Cloud NDB and Cloud Tasks libraries… congratulations!
Next steps
To do this exercise yourself, check out our corresponding codelab which leads you step-by-step through the process. You can use this in addition to the video, which can provide guidance. You can also review the push tasks migration guide for more information. Arriving at a fully-functioning Module 8 app featuring Cloud Tasks sets the stage for a larger migration ahead in Module 9. We've accomplished the most important step here, that is, getting off of the original App Engine legacy bundled services/APIs. The Module 9 migration from Python 2 to 3 and Cloud NDB to Cloud Firestore, plus the upgrade to the latest version of the Cloud Tasks client library are all fairly optional, but they represent a good opportunity to perform a medium-sized migration.
All migration modules, their videos (when available), codelab tutorials, and source code, can be found in the migration repo. While the content focuses initially on Python users, we will cover other legacy runtimes soon so stay tuned.
You can now send an email archive of Google Chat messages to a 3rd party archiving solution.
For users that have archiving of Chat messages enabled, the 3rd party archiving solution will be able to receive email archives containing 1:1 conversations and conversations in rooms and groups. Content within the Chat message is also archived, such as reactions, Drive links, and file attachments.
Who’s impacted
Admins and developers
Why it’s important
If you’re required to archive Chat messages for compliance purposes, or are already using a 3rd party archiving solution, you’ll now be able to integrate Google Chat with these 3rd-party partners.
Available to Google Workspace Enterprise Standard, Enterprise Plus, Education Fundamentals, Education Plus customers
Not available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Frontline, and Nonprofits, as well as G Suite Basic and Business customers