[MGNLHOOK-306] Get workspace from path, for Norsu content Created: 13/Dec/22  Updated: 16/Feb/23  Resolved: 10/Feb/23

Status: Closed
Project: Magnolia Webhooks
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: 2.0.0

Type: Story Priority: Neutral
Reporter: Javier Benito Assignee: Javier Benito
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: 1d 3h Time Spent: 1d 1h
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLHOOK-332 Implement fix Technical task Completed Javier Benito  
MGNLHOOK-333 Review Technical task Completed Jaroslav Simak  
MGNLHOOK-334 Pre-Integration QA Technical task Completed Chuong Doan Huy  
MGNLHOOK-335 QA Technical task Completed Oanh Thai Hoang  
Team: DeveloperX
Testcase included:
Yes
Date of First Response:
Epic Link: Webhooks on SaaS (Phase 2)
Sprint: DevX 30
Story Points: 2

 Description   

Problem

Webhooks module still relies on workspace as a filtering property. It is also still sent as data in the event. There is no workspace concept on Norsu, so we need to use content types approach instead.

Suggested solution

For webhooks on Norsu, we would get rid of the workspace concept, using content types approach instead.

Note

We would need to discuss/decide if we keep compatibility for workspace on Webhooks based on JCR (2.0.0), as they share the same code base as Webhooks based on Norsu.



 Comments   
Comment by Javier Benito [ 17/Jan/23 ]

Background

  • Webhook events, have a property named workspace, as part of the payload sent to the target endpoint:
{"eventId": "d6b3eecf-8c01-4c21-9137-f00f5f52a1fc", "eventDate": "2023-01-17T14:41:30.508", "eventType": "Published", "path": "dam.yx4vmzeixchwif79.beta.de.magnolia-cloud.com/Screenshot 2023-01-17 at 15.35.31.png", "recursive": false, "nodeType": "mgnl:asset", "workspace": "website", "environment": "main"} 
  • workspace is also a property key in the filtering grammar, that can be used while filtering events, for example:
filter: "@workspace = 'website'" 
  • We also have an optional property, called entity on each webhook event definition, which is unused, because its main goal in the beginning was to be able to specify the kind of content each event was targeting.

Proposed solution for Dx Core 6.3 and SaaS (both JCR and Norsu content)

 
As every content on Magnolia will be backed on a content type, the proposal is to move both, workspace and entity concepts to a contentType approach.
 

  • Regarding workspace as part of the payload, we can rename it to contentType and fill it accordingly:
    • Norsu: Getting the contentType from the norsu datasource definition (MGNLUI-7703), which will be injected in every action where we trigger a webhook event for a Norsu content (NorsuPublishAction, NorsuUnpublishAction, etc).
    • JCR: Getting the belonging contentType for the workspace of the source JCR node, by querying the Content Type Registry.
  • Rename the entity property for webhook event definitions, to contentType, stating clearly in this way that the event will only be triggered for that content type. It will still be optional. We could let it have multiple values, if we find it adds value to the filtering (to discuss).
  • Events will be filtered based on this property, instead of workspace grammar property, if it's provided in the event definition. In order to do that, we will query the contentType property on the detected event, as it is being done now with workspace.
  • For workspace as a filtering property, the proposal is to remove it, as the filtering will be done as detailed in the previous step.

 

Comment by Christopher Zimmermann [ 17/Jan/23 ]

For Norsu - I think that is fine.

For JCR - I have some doubts about removing support for workspace. Workspace is a key concept and is heavily used on DXCore. One consideration is that it is possible to have multiple contentTypes using the same workspace. So you there can be a situation where given a workspace - you don't know which contenttype it relates to.
As webhooks is still new - I think it would be possible to force customers to use the contentType approach, and they can creaate "slim contenttype" definitions for their existing apps. But for some it will feel like a lot of "boilerplate" / extra complicated, just to setup a webhook.

Comment by Javier Benito [ 17/Jan/23 ]

Ok, understood.

Sure, if they want to filter by the workspace where they have their existing apps, they should create content types for it to do that. The change would be from this setup (with the current implementation):

events:
  - name: contentPublished
    eventType: Published
    filter: "@workspace = 'workspace1'"

to:

events:
  - name: contentPublished
    contentType: contentType1, contentType2, contentType3
    eventType: Published

The problem we're facing now on SaaS, is that we support triggering on JCR and Norsu, and the filtering grammar (which has the ability to filter by workspace, if provided), is common for all contents. So we can have the first definition stated in this comment, which is true for JCR but is false for Norsu. A solution that comes to my mind to provide compatibility while JCR goes away, is to move the workspace filtering from the filtering grammar to a property itself, like contentType. Something like:

events:
  - name: contentPublished
    contentType: contentType1, contentType2, contentType3
    workspace: workspace1, workspace2, workspace3
    eventType: Published

stating clearly in documentation that workspace property relates to JCR and contentTypes to Norsu content, and they don't work together for the same content triggered (which in fact will be true, a given content can only by from Norsu or JCR, right?)

Comment by Javier Benito [ 18/Jan/23 ]

Flag added

Flagged until more discussions are taken, further details on https://www.notion.so/magnoliacms/Webhooks-and-Workspace-d6ff587a3ec6402fba91397955e51c3f

Generated at Mon Feb 12 10:02:58 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.