make stream posts immutable on specific entities?

[hi-ko]

I use scripting to post bpmn task comment to the entity stream. Is there a way to make a stream post immutable after submit to make these comments traceable / audit-proof? At the moment a user can always edit/remove his comments in a stream.
If there is better option to create entries in the entity stream from workflow steps like the status change, please let me know.

edit: I found https://github.com/espocrm/espocrm/issues/825, so there is no support at all to limit permissions on own stream posts? Any work around? Like in ticket or chat systems a user should not or only be allowed to edit or delete a post only for a short time frame (e.g. 10 mins).

[hi-ko]

A nice feature for the BPMN processes would be a stream task to persist decisions like "reviewed" or "approved" with it's comment in the related entity stream. A combination of status and post entry but read only like the status change.

[item]

maybe : https://docs.espocrm.com/administrat...params/#stream
noteEditThresholdPeriod – '7 days' – how much time is available for editing stream posts;
noteDeleteThresholdPeriod – '1 month' – how much time is available for deleting stream posts;

[hi-ko]

After playing around with the options we already have for BPMN user tasks I would vote for a new stream note type like "workflow task update" which should be added to the stream of a linked entity and which could contain something like (translated):
"{$user} completed [{$taskType}](/#BpmnUserTask/view/$userTaskId) with resolution: {$resolution} {$resolutionNote}"

In the meantime I try to fill the gap by creating several script tasks calculating and adding a new Note record of type 'Post' containing the resolution of a task, but then I need to restrict noteEditThresholdPeriod/noteDeleteThresholdPeriod to a minimum to avoid any unwanted modification of already published decisions.

[rabii]

that would be nice and would set a history on target entity but i think it will need more details because one targetEntity could be triggered multiple times by the same flowchart/workflow.

[hi-ko]

sure - and therefore I would expect n entries for n task executions. A task is unique as a child of a process. If we have a separate type we could filter by "workflow task update". I'm actually trying to implement the requirement that not only the entity status change, done by a bpmn script task, should be audited in the entity stream but also any user task feedback/resolution which is done as a multiinstance subprocess

[yuri]

Only admin can edit all notes. A regular user can edit only own post. If the the post note record you are creating has Created By = System User, then nobody should be able to edit the record (except admin I believe).

[hi-ko]

I already tried that before but it seems the following command in a separate scriptTask ignores the createdBy parameter:

$note = record\create('Note',
'parentId', bpm\processEntity\attribute('targetId'),
'parentType', bpm\processEntity\attribute('targetType'),
'post', $entityPost,
'type', 'Post',
'createdBy','system'
);

Do we need a runAs concept in workflow scripts not open the door?