Storing and managing module-specific data in Zoho Sprints extensions

Storing and managing module-specific data in Zoho Sprints extensions

Storing and handling data related to Zoho Sprints modules is a key necessity when managing an extension. In this post, we'll look at the advantages of data storage and how it can be used with an example demonstration.

Data storage

An introduction

In general, storing data makes it easier to access it later when there is a need to perform the relevant functionalities. Zoho Sprints allows you to store, retrieve, edit, and delete module-specific data while handling widgets in an extension. You can check out details on data storage in this documentation.


The supported Zoho Sprints modules

Zoho Sprints currently supports data storage across these modules:
  1. Item - GET | SET | UPDATE | DELETE
  2. Sprint - GET | SET | UPDATE | DELETE
  3. Release - GET | SET | UPDATE | DELETE
  4. Meeting - GET | SET | UPDATE | DELETE
  5. Projects - GET | SET | UPDATE | DELETE
  6. Timesheet - GET | SET | UPDATE | DELETE
  7. Epic - GET | SET | UPDATE | DELETE
There are individual APIs to get, set, update, and delete module-specific data in Zoho Sprints. You can refer to the data storage APIs for each of these operations linked above.

Use case scenario

Consider the following scenario: a team member handles a feature request as a release in Zoho Sprints. Assume they completed the feature and finished the release, and they recorded a release note. Now, say a new enhancement request arrives for the same feature, and another team member is required to work on it. It would be best if the new member reviewed the previous release notes before commencing the feature enhancement.

In this case, a widget can be created to allow members to log their release notes, including the date and version. When a new member begins their enhancement work, they can refer to previously logged release notes and versions to proceed with their work. Once completed, they can log their own release notes accordingly.


Steps to implement this use case
  1. Create a connection
  2. Create an extension and configure its plugin-manifest.json file
  3. Create a widget to handle the data storage logic
Let's go over each of these processes in depth using an example.

1. Create a connection
  1. Go to Sigma and navigate to the Connections section in the left panel of your Sigma workspace.
  2. Choose Zoho Sprints as the service from the dropdown list, then select your Zoho Sprints organization.
  3. Create a default connection for Zoho Sprints to fetch release details, store data, and retrieve extension storage data, ensuring that the required API scopes specified in the documentation are correctly added. Refer to our previous post on connections for guidance.


2. Create an extension and configure a widget in the plugin-manifest.json file
  1. Navigate to the Extensions section in the left panel of your Sigma workspace.
  2. Click the New Extension button and create a new extension. You can refer to this post for detailed guidance on creating a new extension.
  3. In the plugin-manifest.json file of the extension, include the sample JSON code that was generated for the Zoho Sprints connections.
  4. Configure a widget by providing the name, the embedding location, and the URL path of the HTML file to be rendered. For our example, a widget with the following details has been created:
➤ name: Log Release Notes
➤ url: The location of the releasenotes.html file (inside app folder) that will render the user interface required for our widget. We'll be creating this widget in the next section of this post.
➤ location: The release right navigation bar
➤ logo: The location of a standard Zoho Sprints logo (logo.svg) that is by default available while creating the extension. You can include and use your customized logo as well.


3. Create a widget to handle data storage logic

Once the connection is created and configured in the plugin-manifest.json file of the newly created extension, the next step is to design the widget that renders the UI and handles the logic to log release notes.

releasenotes.html file - The code is added as an attachment to the post.
  1. In the above code snippet, the mandatory init method is invoked in order to use the other required JS SDK methods. Then, the method to get the current location details is invoked. For our example, this method returns the release details which include the extension ID, team ID, project ID, user ID, and release ID.
  2. Using the retrieved details, the Zoho Sprints API to get extension release data is invoked. This API checks if any data has been stored against the release. If yes, it returns a status code of 200; else, it returns 404, which means no data was discovered.
  3. If the code is 200, the widget's Previous Release Notes section displays any previously recorded release data. If it's 404, the end user is presented with the message "No prior release notes."
➤ In our example, when the end user (member) accesses the widget for the first time, no release data would have been logged, so it will return code 404 and display the message accordingly.
  1. Next, under the widget's section to add new release data (notes, date, and version), the user enters the current release notes and clicks the button Add release note. Here, the Zoho Sprints API to set extension release data is invoked. This method requires a "If-Match" header parameter with an ETag as its value.
➤ ETag is an identifier that's generated each time data is stored. When storing data for the first time, the "If-Match" parameter can be an empty string.
➤ When the method is invoked, the data entered by the end user, including the release notes, release data, and version, is saved, and an ETag value is returned.
  1. The next time the widget is opened, the get extension release data API is invoked again. This time, because data has been stored, code 200 will be returned, and the data and its related ETag will be fetched and displayed to the end user in the Previous Release Notes section.
  2. When saving the most recent data using the set extension release data API, the previous ETag will be given to the header. Once the new data is stored, a new ETag is generated, and the cycle continues.
This way, the end user is prompted every time with the previous logged release note, helping them check and log their own.

Testing the extension

Once the development is completed, you can test the extension using the Run option in the Sigma cloud editor.


In this post, we explored the concept of storing and retrieving the data stored in the release module. Using this, you can get, set, update, and delete data for the supported modules in Zoho Sprints using the data storage concept. We hope you found this post useful. Keep following this space for more updates. Stay tuned!


SEE ALSO

Zoho Sprints developer platform features and capabilities
Creating seamless integrations with connections


<<Previous