[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: |
|
|||||||||||||||||||||||||
| Team: | ||||||||||||||||||||||||||
| Testcase included: |
Yes
|
|||||||||||||||||||||||||
| Date of First Response: | ||||||||||||||||||||||||||
| Epic Link: | Webhooks on SaaS (Phase 2) | |||||||||||||||||||||||||
| Sprint: | DevX 30 | |||||||||||||||||||||||||
| Story Points: | 2 |
| Description |
| Comments |
| Comment by Javier Benito [ 17/Jan/23 ] |
Background
{"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"}
filter: "@workspace = 'website'"
Proposed solution for Dx Core 6.3 and SaaS (both JCR and Norsu content)
|
| 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. |
| 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 ] |
|
Flagged until more discussions are taken, further details on https://www.notion.so/magnoliacms/Webhooks-and-Workspace-d6ff587a3ec6402fba91397955e51c3f |