Hi Shelley,

Do you have a screenshot of the error that you can share?

-Scotty

Ahh - the 'operation is not permitted' tend to be due to the new security checks that the workgroup server is performing.

For a more specific error, there should be a correlating entry on the TRIMWorkgroup log on the server the user was connected to in question. 

Some of these have been bugs, which OpenText has been resolving/hotfixing.

I recommend finding the matching TRIMWorkgroup Entry which will let you know the specific server side security check that failed and then logging a case with OpenText.

-Scotty

Thanks Scotty the unusual thing is that we did not have this issue in our preprod environment it is only happening in the prod environment so we are also trying to assess what the differences are between them.

Also Administrators can use the Sent to mail function

In that case, the TRIMWorkgroup log on the server does let you know what check in particular failed - that may give you an avenue to look at for the difference between the two environments. 

From my own testing, usually its due to a failed access control check of some sort. If they are trying to send it to a particular TRIM location, check the 'Can Use' permissions against those locations as well.

I'd say its getting caught on an access control somewhere as Admins typically have Bypass Access Controls (which would be why its working for Admins)

-Scott

I will let you know how we go

HI Scotty,

This is the error message in the log String Server-side validation failed for the permission Create communications [ INSERT INTO TSTRANSMIT ( uri , trRecordUri , trDateTime , trMedium , trDirection , sysLastUpdated , sysLastUpdatedBy ) VALUES

the issue does not happen with Admin profile.  We have tried enabling all settings on the user types but all other users except Admin still have this issue.  Any suggestions?? 

Hmm Curious - The above specifically mentions the 'Create Communications' permission.

As long as the 'Create Communications' under the Record Permissions for a staff member you are testing with is ticked it sounds like something deeper than the permission itself.

Does creating a NEW location (normal permissions) manually with that specific permission ticked solve the issue?

Have seen some locations 'quirk out' in the past and re-creating as a new location has helped. If so, and it works, points to a potential table problem possibly not picking the established permission up correctly.

-Scotty

When we create a new User Type the user can Send to Mail but their Favourite records are lost even though they are using the same login etc.  We are now trying to determine if/where the tables are at fault.