If notifications are enabled, notify users when an entity is published or unpublished #4556

Add publish/unpublish mail notifications for entities

Background

Mica already sends mail notifications when an entity moves through the editorial workflow (draft -> under review -> deleted) via EntityPublicationFlowMailNotification. However, no notification is sent when an entity is actually published or unpublished. This means editors who submitted a
document for review never learn when it goes live.

Notifications will reuse the existing per-entity config flags (isStudyNotificationsEnabled, isNetworkNotificationsEnabled, etc.) - no new config fields needed.

Changes

mica-core

• New class org.obiba.mica.core.notification.EntityPublishedMailNotification
  • Extends PublicationFlowMailNotification
  • Method signature: send(String id, String typeName, boolean published)
  • Reuses existing notification-enabled flags per typeName (same as EntityPublicationFlowMailNotification)
  • Template name convention: "%sPublished" -> e.g. individualStudyPublished
  • Subject: reuses existing per-type subject config (e.g. studyNotificationsSubject)
  • ACL lookup: /draft/{typeName} for both the specific id and * (all instances)
  • Recipients: filtered by "EDIT" action - captures both MICA_EDITOR (ADD, VIEW, EDIT) and MICA_REVIEWER (ADD, VIEW, EDIT, DELETE, PUBLISH) without abusing a RevisionStatus value
• Update AbstractGitPersistableService
  • Inject EntityPublishedMailNotification
  • In publishState(String id): call entityPublishedNotification.send(id, getTypeName(), true) after saving state
  • In unPublishState(String id): call entityPublishedNotification.send(id, getTypeName(), false) after saving state
  • Guard calls with a null-check on getTypeName() (base AbstractStudyService returns null; concrete subclasses return the correct type name)

Agate (mail templates)

• individualStudyPublished
• harmonizationStudyPublished
• networkPublished
• collectedDatasetPublished
• harmonizedDatasetPublished
• projectPublished

Template context variables:

• organization => portal name
• publicUrl => portal public URL
• documentId => entity identifier
• documentType => entity type name (e.g. individual-study)
• published => true = published, false = unpublished

Notes

• The existing EntityPublicationFlowMailNotification handles workflow status transitions (draft -> under review -> deleted). This new notification is complementary and fires only on the actual publish/unpublish action.
• Filtering by "EDIT" action is intentional: both EDITOR_ACTIONS and REVIEWER_ACTIONS include "EDIT", so both groups are notified without needing to enumerate them explicitly. EDITOR can put entity TO UNDER_REVIEW and should know that the REVIEWER published it.
• getTypeName() resolves polymorphically - no changes needed to individual service classes.