Skip to main content

Message Registry Service - Consultation test scenarios

This list of Message Registry consultation scenarios can help a Document Provider validate a message registry service. The scenarios follow the e-Box Message Registry open API Spec 3.0 or above. This list is not exhaustive but try to cover the possible use cases that are likely to occur.

Data needed​

The scenarios implies that these data exists:

  • An ebox enterprise and a human user who have access to consult it. It means that the user has consultation access to the general partition.
  • Let the consulted e-Box have at least 11 messages in the general partition to test the pagination
  • Let partitionBid be a partition that the user has a consultation access to.
  • Let partitionToDelete be a partition that the user has a consultation access to.
  • Let messageIdInPartitionB be a message in partition partitionBid.
  • Let partitionIdNoAccess be a partition that the user has not a consultation acess to. Let 1 be the ID of its attachment.
  • Let messageId1document be the identifier of a message containing a document, preferably a PDF. Let 1 be the ID of its main attachment.
  • Let messageTestInTitle be the identifier of a message with the word "test" in the title.
  • Let sentMessageId be the identifier of a message sent from the partition partitionBid.
  • Let noAccessMessageId be the identifier of a message in partition partitionIdNoAccess.
  • Let messageIdNearlyExpired be the identifier of an unread message expiring in less than 15 days in partition general.
  • Let messageIdToMove1 be a message in general partition.
  • Let messageIdToMove2 be a message in general partition.
  • Let messageIdToMove3 be a message in partition partitionToDelete.
  • Let messageIdToMove4 be a message in partition partitionToDelete.

If the Document Provider supports more than one document in a message

  • Let messageId2documents be the identifier of a message containing one document and one annex. Let 2 be the ID of the annex attachment.

If the Document Provider supports reply feature

  • Let repliableMessageId be the identifier of a message with reply authorized and without message action.
  • Let replyNotAuthorizedMessageId be the identifier of a message with property isReplyAuthorized set to false.

If the Document Provider supports the for_action feature, which means a message containing a message action of type requiredActionToConfirm

  • Let requiredActionId be the identifier of a message action of type requiredActionToConfirm
  • Let messageIdRequiredAction be a message with a message action of type requiredActionToConfirm without due date.

If the Document Provider support body content, which means a free text attached to the message

  • Let messageIdWithBody be a message with a body content.

If the Document Provider supports registered mails

  • Let registeredMailId be the identifier of a registered mail.

Message list scenarios​

There is a large amount of possible scenarios on the use of the GET /ebox/messages request due to the large number of parameters.

  • GET /ebox/messages?page=1&pageSize=10 We expect to get 10 messages if the e-Box contains at least 10 messages. We expect messages from the general partition and the partition partitionBid if the user has access to. Please check that the message partitionIdNoAccess is not in the response.
  • GET /ebox/messages?page=2&pageSize=10 We expect to get other messages in a number up to 10 if the e-Box contains more than 10 messages from general and partitionBid partitions. Please check that the message partitionIdNoAccess is not in the response.
  • GET /ebox/messages?page=1&pageSize=10&q=test&qlang=fr We expect all messages containing the word "test" in the french title like the message messageTestInTitle. Please read the section about text search feature for more details.
  • GET /ebox/messages?page=1&pageSize=10&folder=out We expect messages sent by the e-Box from the partitions that the user has a consultation access to.
  • GET /ebox/messages?page=1&pageSize=10&visible=false We expect all hidden messages in partitions that the user can consult
  • GET /ebox/messages?page=1&pageSize=10&visible=true&recipientPartition=partitionBid We expect all messages that are in partition partitionBid if the user has access to.
  • GET /ebox/messages?page=1&pageSize=10&visible=true&recipientPartition=partitionIdNoAccess We expect a 200 with zero message.
  • GET /ebox/messages?page=1&pageSize=10&expiredBefore=2023-06-16&read=false&visible=true We expect all unread visible message that expire soon like messageIdNearlyExpired. The alert button in the ebox Enterprise portal for nearly expired message does this request with the date of today + 16 days.
  • GET /ebox/messages?page=1&pageSize=10&read=false&visible=true&registeredMail=true&folder=in If the Document Provider does not support registered mail, we expect 0. Else, we expect the unread visible registered mails like the message registeredMailId. The alert button in the ebox Enterprise portal for registered mails does this request.
  • GET /ebox/messages?page=1&pageSize=10&visible=true&requiredAction=true&folder=in If the Document Provider does not support the message action of type requiredActionToConfirm then we expect a void list. Else we expect visible message with a message action of type requiredActionToConfirm such as messageIdRequiredAction and messageIdRequiredActionAndDueDate. The action required list in ebox Enterprise portal does this request.
  • GET /ebox/messages?page=1&pageSize=10&receivedBefore=2024-01-02&visible=true&enterpriseNumber=0206731645&expiredBefore=2023-06-16&folder=in There are also several filters that can be combined in the ebox Enterprise portal. The current available filters in the portal are receivedAfter, receivedBefore, enterpriseNumber, senderApplicationId, registeredMail, expiredBefore, read, q and qlang.
  • GET /ebox/messages?page=1&pageSize=10&receivedAfter=2023-05-01&q=test&qlang=FR&folder=out The filters can be applied for the sent-box too.

Message details scenarios​

  • GET /ebox/messages/messageId1document We expect the message details.
  • GET /ebox/messages/noAccessMessageId We expect a 404 error.

Document download scenarios​

  • GET /ebox/messages/messageId1document/attachments/1/content We expect the file content.
  • GET /ebox/messages/messageId1document Since the document is downloaded in previous scenario, we expect the value of isRead become true.
  • GET /ebox/messages/noAccessMessageId/attachments/1/content We expect a 404 error.

If the Document Provider support more than one document in a message

  • GET /ebox/messages/messageId2documents/attachments/2/content We expect the annex file content.
  • GET /ebox/messages/messageId2documents Since the downloaded document is not the main content and none of the previous scenario downloaded the main content, we expect the value of isRead still false.

Move messages scenarios​

  • POST /ebox/messages/changePartition
{
  "messageIds": ["messageIdToMove1", "messageIdToMove2"],
  "targetRecipientPartitionId": "partitionBid"
}

We expect both messages moved to partition partitionBid.

  • POST /ebox/messages/changePartition
{
  "messageIds": ["partitionIdNoAccess", "messageIdToMove1", "messageIdToMove2"],
  "targetRecipientPartitionId": "partitionBid"
}

We expect a 400 error since the user has no access to consult the partition that contains partitionIdNoAccess.

  • POST /ebox/messages/changePartition
{
  "messageIds": ["messageIdToMove1", "messageIdToMove2"],
  "targetRecipientPartitionId": "partitionIdNoAccess"
}

We expect both messages moved to partition partitionIdNoAccess even if the user has no access to.

  • POST /ebox/messages/changePartition
{
  "sourcePartitionId": "partitionToDelete",
  "targetRecipientPartitionId": "GENERAL",
  "targetSenderPartitionId": "partitionBid"
}

We expect all message from partition partitionToDelete moved to the general partition. We expect also that for all messages sent from partitionToDelete that the sender partition change to partitionBid. This request will occur when an administrator want to delete a partition. It is possible that the source partition does not contain any message. In this case, the Document Provider web service returns also a successful 204 response.

change visibility scenarios​

  • POST /ebox/messages/changeVisibility
{
  "messageIds": ["messageId1document"],
  "isVisible": false
}

We expect the message messageId1document to not being visible anymore

Statistics scenarios​

  • GET /ebox/messages/statistics/nearlyExpired?numberOfDaysBeforeExpiration=15&isRead=false We expect at least one because of the message messageIdNearlyExpired. The alert button in the e-Box Enterprise portal appears if the result of this request is more than 0.
  • GET /ebox/messages/statistics/withActionRequired?isConfirmed=false If the Document Provider does not support message action of type requiredActionToConfirm then we expect always 0. Else We expect at least one because of the message messageIdRequiredAction. The required action counter in e-Box Enterprise portal is the result of this request.
  • GET /ebox/messages/statistics/registeredMails?isRead=false If the Document Provider does not support registered mails, then we expect always 0. Else we expect at least one because of the message registeredMailId. The alert button in the e-Box Enterprise portal appears if the result of this request is more than 0.

Consult body scenarios​

Scenarios for Document Provider who support body content

  • GET /ebox/messages/messageIdWithBody/body We expect the body content.
  • GET /ebox/messages/messageIdWithBody If isBodyMainContent is true, then because we get the body content in previous scenario then we expect the value of isRead become true.

reply scenarios​

Scenarios for Document Providers who support the reply feature

  • POST /ebox/messages/repliableMessageId/reply
messageToReply:{"sender":{"eboxType":"enterprise","enterpriseNumber":"0123456789"},"bodyContent":{"fr":"this is the body of my reply"},"attachments":[{"httpPartName":"upfile1","isMainContent":"true"}]}

We expect a 201

  • POST /ebox/messages/replyNotAuthorizedMessageId/reply
messageToReply:{"sender":{"eboxType":"enterprise","enterpriseNumber":"0123456789"},"bodyContent":{"fr":"this is the body of my reply"},"attachments":[{"httpPartName":"upfile1","isMainContent":"true"}]}

We expect a 400 bad request

Messages with action required scenarios​

Scenarios for Document Providers who support the message with message action of type requiredActionToConfirm

  • GET /ebox/messages?requiredAction=true&requiredActionNotExecuted=true We expect the message messageIdRequiredAction in it.
  • GET /messageActions/requiredActionId We expect anything with type requiredActionToConfirm and without URL neither templateId.
  • PATCH /ebox/messages/messageIdRequiredAction/messageActions/requiredActionId
{"isExecuted": true}

We expect a 204.

  • GET /ebox/messages?requiredAction=true&requiredActionNotExecuted=true Because action in message messageIdRequiredAction is marked as executed in previous scenario, we expect to not see this message anymore with the filter requiredActionNotExecuted.
  • PATCH /ebox/messages/messageIdRequiredAction/messageActions/requiredActionId
{"isExecuted": false}

We expect a 204.

Document Consumer scenarios​

Document Consumers are applications authorized to consult all the e-Box of their own enterprise. They have the right to consult all received and sent messages in any partition of their own e-Box. See The introspect examples to know how to distinct Document Consumer applications.

  • GET /ebox/messages We expect 25 messages or less. According to the 3.0 API the default pagination is the first page of 25 messages.
  • GET /ebox/messages/noAccessMessageId/attachments/1/content We expect a success and the document file content.
  • GET /ebox/messages without scope scope:document:management:consult:ws-eboxrestentreprise:messagesfull We expect a 403 error.