Dear Alison

thank you for sharing your ideas, but I disagree. We are talking about important term data (several hundreds of termbases) managed on a server for hundreds of users each with very specific access rights at entry and term levels (BTW some users cannot edit or delete entries).

So it would be completely nonsense to let users without admin rights delete a complete termbase without any control, even if the delete comand must be confirmed with a second clic. 

For example in Multiterm Administrator 2015 (or Admin pane in Multiterm 2019) you must first stop a termbase and you must deconnect any users before you can delete a termbase.

This is a very serious bug from my point of view.

Regards,

Bruno

Dear Alison

thank you for sharing your ideas, but I disagree. We are talking about important term data (several hundreds of termbases) managed on a server for hundreds of users each with very specific access rights at entry and term levels (BTW some users cannot edit or delete entries).

So it would be completely nonsense to let users without admin rights delete a complete termbase without any control, even if the delete comand must be confirmed with a second clic. 

For example in Multiterm Administrator 2015 (or Admin pane in Multiterm 2019) you must first stop a termbase and you must deconnect any users before you can delete a termbase.

This is a very serious bug from my point of view.

Regards,

Bruno

Bruno Ciola

Bruno Ciola said:

thank you for sharing your ideas, but I disagree. We are talking about important term data (several hundreds of termbases) managed on a server for hundreds of users each with very specific access rights at entry and term levels (BTW some users cannot edit or delete entries).

I wonder if Ali missed the point that you are working with server databases and access can be given to many users?

You could try reproducing the issue with the "guest" user, which should, by definition not have any write permissions.