MeshFlowsGPL/meshflows
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages 24 Wiki Activity Actions

Policies op de triggers redesign #41

New issue
Closed
opened 2026-08-04 07:45:56 +00:00 by meshflows · 8 comments
meshflows commented 2026-08-04 07:45:56 +00:00
Owner
Copy link

Voor de redesign van de policies op de trigger zou ik graag voor inbound en outbound policies willen kunnen definieren en ook een policy keten. Dus bijvoorbeeld een policy die van XML naar JSON gaat of van JSON naar XML. Ook wil ik een policy kunnen hebben die headers valideert of een policy die throttled. Ik verwacht dat ik op basis van de gebruiker van het token/oauth eventueel een andere throttle policy kunnen kiezen. Het zou ook mooi zijn als we een soort van designer hebben die het wat beter grafisch toont.

Voor de redesign van de policies op de trigger zou ik graag voor inbound en outbound policies willen kunnen definieren en ook een policy keten. Dus bijvoorbeeld een policy die van XML naar JSON gaat of van JSON naar XML. Ook wil ik een policy kunnen hebben die headers valideert of een policy die throttled. Ik verwacht dat ik op basis van de gebruiker van het token/oauth eventueel een andere throttle policy kunnen kiezen. Het zou ook mooi zijn als we een soort van designer hebben die het wat beter grafisch toont.
Marc commented 2026-08-04 07:49:00 +00:00
Contributor
Copy link

Kun je verduidelijken of de policy chain alleen lineair moet zijn, of dat conditionele stappen/vertakkingen per trigger ook ondersteund moeten worden?

Kun je verduidelijken of de policy chain alleen lineair moet zijn, of dat conditionele stappen/vertakkingen per trigger ook ondersteund moeten worden?
meshflows commented 2026-08-04 07:52:14 +00:00
Author
Owner
Copy link

Ik verwacht een liniaire policy chain. Ik denk dat de ploicies die gebruiker specifiek zijn op die plek gezet moeten worden als policy chain. Ik zoui ook een gebruiker een set van API's willen kunnen toewijzen als een product en een product kan dan ook een ploicy chain hebben. Door policy chains te houden denk ik dat het helderder blijft dan via vertakkingen.

Ik verwacht een liniaire policy chain. Ik denk dat de ploicies die gebruiker specifiek zijn op die plek gezet moeten worden als policy chain. Ik zoui ook een gebruiker een set van API's willen kunnen toewijzen als een product en een product kan dan ook een ploicy chain hebben. Door policy chains te houden denk ik dat het helderder blijft dan via vertakkingen.
Marc commented 2026-08-04 08:11:08 +00:00
Contributor
Copy link

Ik pak dit op via branch feature/issue-41-policies-triggers-redesign.

Voordat ik inhoudelijk verder ga, heb ik nog een paar verduidelijkende vragen over het trigger-redesign:

  1. Welke soorten policies moeten op triggers ondersteund worden in deze redesign?
  2. Moet dit backward compatible blijven met bestaande triggerdefinities of mogen we het model breken/opruimen?
  3. Wat is de gewenste volgorde of precedence als meerdere policies tegelijk van toepassing zijn?
  4. Gaat het alleen om runtime-evaluatie, of ook om validatie/UI/configuratie in de editor/API?
  5. Zijn er al concrete voorbeelden of acceptatiecriteria waar deze redesign aan moet voldoen?

Als je wilt, werk ik daarna meteen een eerste technische richting of implementatievoorstel uit.

Ik pak dit op via branch `feature/issue-41-policies-triggers-redesign`. Voordat ik inhoudelijk verder ga, heb ik nog een paar verduidelijkende vragen over het trigger-redesign: 1. Welke soorten policies moeten op triggers ondersteund worden in deze redesign? 2. Moet dit backward compatible blijven met bestaande triggerdefinities of mogen we het model breken/opruimen? 3. Wat is de gewenste volgorde of precedence als meerdere policies tegelijk van toepassing zijn? 4. Gaat het alleen om runtime-evaluatie, of ook om validatie/UI/configuratie in de editor/API? 5. Zijn er al concrete voorbeelden of acceptatiecriteria waar deze redesign aan moet voldoen? Als je wilt, werk ik daarna meteen een eerste technische richting of implementatievoorstel uit.
meshflows commented 2026-08-04 08:16:26 +00:00
Author
Owner
Copy link
  1. Er zijn nu een paar policies. Deze hoeven niet als basis te dienen. Een throttle policy, een oauth policy (voor bijvoorbeeld uitgaande API), een xml->json en omgekeerd policy en een vullen van headers of verwijderen van headers policy lijken zinvol op dit moment.
  2. hoeft niet backward compatilble te zijnn
  3. liniair bepaald de volgorde. waarbij globaal -> product -> user -> API
  4. Policies zijn runtime maar ik wil ze natuurlijk in het dashboard wel kunnen zetten en de volgorde (min of meer) kunnen sturen. Dus op API niveau met 2 policies bepaal ik de volgorde.
  5. Ik wil de policies kunnen zetten in een volgorde op API, product, user, globaal (als in http, schedule of AMQP) niveau. En ik wil de policies in unittests kunnen testen.
1) Er zijn nu een paar policies. Deze hoeven niet als basis te dienen. Een throttle policy, een oauth policy (voor bijvoorbeeld uitgaande API), een xml->json en omgekeerd policy en een vullen van headers of verwijderen van headers policy lijken zinvol op dit moment. 2) hoeft niet backward compatilble te zijnn 3) liniair bepaald de volgorde. waarbij globaal -> product -> user -> API 4) Policies zijn runtime maar ik wil ze natuurlijk in het dashboard wel kunnen zetten en de volgorde (min of meer) kunnen sturen. Dus op API niveau met 2 policies bepaal ik de volgorde. 5) Ik wil de policies kunnen zetten in een volgorde op API, product, user, globaal (als in http, schedule of AMQP) niveau. En ik wil de policies in unittests kunnen testen.
Marc commented 2026-08-04 08:38:57 +00:00
Contributor
Copy link

Implementatie van de policy-chain redesign staat op branch feature/issue-41-policies-triggers-redesign.

Opgeleverd:

  • Lineair chain-model: global → product → user → API
  • Types: throttle, headers, xml_json, oauth_outbound (+ unit tests)
  • Identity: product.policy_chain, user policy chains, global chains API
  • Gateway past inbound/outbound transforms echt toe
  • Trigger veld: invocation.policy_chain
  • Dashboard: PolicyChainEditor voor product, user en global chains
  • Docs/voorbeeldpolicies bijgewerkt (geen backward compatibility)

Nog te doen indien gewenst: PR aanmaken en CI op de feature-branch laten lopen.

Implementatie van de policy-chain redesign staat op branch `feature/issue-41-policies-triggers-redesign`. Opgeleverd: - Lineair chain-model: global → product → user → API - Types: throttle, headers, xml_json, oauth_outbound (+ unit tests) - Identity: product.policy_chain, user policy chains, global chains API - Gateway past inbound/outbound transforms echt toe - Trigger veld: invocation.policy_chain - Dashboard: PolicyChainEditor voor product, user en global chains - Docs/voorbeeldpolicies bijgewerkt (geen backward compatibility) Nog te doen indien gewenst: PR aanmaken en CI op de feature-branch laten lopen.
Marc commented 2026-08-04 08:41:25 +00:00
Contributor
Copy link

Update: de redesign is nu geïmplementeerd op branch feature/issue-41-policies-triggers-redesign.

Referenties:

Opgeleverd in deze wijziging:

  • Lineaire keten: global → product → user → API
  • Nieuwe policy types: throttle, headers, xml_json, oauth_outbound
  • Identity-laag voor product/user/global chains
  • Dashboard editor voor product-, user- en global policy chains
  • Trigger invocation.policy_chain
  • Tests en docs bijgewerkt
Update: de redesign is nu geïmplementeerd op branch `feature/issue-41-policies-triggers-redesign`. Referenties: - Commit: `c772aa3` — Redesign trigger policy chains across gateway and dashboard. - PR / compare: https://code.meshflows.org/MeshFlowsGPL/meshflows/compare/main...feature/issue-41-policies-triggers-redesign Opgeleverd in deze wijziging: - Lineaire keten: global → product → user → API - Nieuwe policy types: throttle, headers, xml_json, oauth_outbound - Identity-laag voor product/user/global chains - Dashboard editor voor product-, user- en global policy chains - Trigger `invocation.policy_chain` - Tests en docs bijgewerkt
Marc commented 2026-08-04 08:52:41 +00:00
Contributor
Copy link

Kleine deploy-notitie: de eerdere policy-uploadfouten bleken vals alarm. De volledige build- en deploy-chain werkte uiteindelijk gewoon door en de wijziging is end-to-end meegekomen.

Kleine deploy-notitie: de eerdere policy-uploadfouten bleken vals alarm. De volledige build- en deploy-chain werkte uiteindelijk gewoon door en de wijziging is end-to-end meegekomen.
Marc commented 2026-08-04 09:05:36 +00:00
Contributor
Copy link

Afronding: deze branch is nu afgesloten met PR #43.

Vervolgwerk voor de policy designer en derived policies staat in issue #42.

Afronding: deze branch is nu afgesloten met PR [#43](https://code.meshflows.org/MeshFlowsGPL/meshflows/pulls/43). Vervolgwerk voor de policy designer en derived policies staat in issue [#42](https://code.meshflows.org/MeshFlowsGPL/meshflows/issues/42).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feature/issue-42-policy-chain-designer
feature/issue-41-policies-triggers-redesign
feature/gateway-edge-decision-and-path-templates
fix/storage-smart-formatting
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
meshflows
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
MeshFlowsGPL/meshflows#41
No description provided.