not sure this is a known bug, but it seams a rather critical issue.
Users can delete termbases from within Multiterm Desktop.
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.
The fact that you mentioned "file explorer" makes me think you are talking about deleting file based termbases. Bruno seems to be talking about deleting server based termbases from the MultiTerm Server in GroupShare.A totally different scenario.
Ae you sure the user you are logging in as has been set up correctly so they don't have permissions to do this?
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?
Dear Bruno,Have you reported this to SDL? It looks quite serious. I could not reproduce with MultiTerm 2015 with GroupShare 2015.Daniel
You could try reproducing the issue with the "guest" user, which should, by definition not have any write permissions.
I should have looked here. It is a known issue:
Apparently it was resolved with the latest GroupShare CU10 just released.
Hi Bruno Ciola, Daniel García Magariños, Paul
I do apologise! I did not read the title fully... I've deleted my initial reply - my bad!
Of course one shouldn't be able to delete a server-based termbase. That's a big ouch!
All the best,
this happens with the Groupshare "translator" roles.
With Multiterm 2015 this option was available only for file-based termbases which makes sense.
In Multiterm 2019 you can delete a server-based TB from the terms>termbases pane, this does'nt make sense. Otherwise why would you have to go to the Administrator pane, disconnect users, remove it and delete it?
thanks for your reference. OK if it was resolved for Groupshare 2017, but it may still be an issue in Groupshare 2015 at that point.
Can you confirm what version you are running as this should have been resolved last year in Cumulative Update 8 - Build 32756 (released 3rd of September 2018).
Apologies... that was a silly question, I see you are using Studio 2019 and MT 2015. The issue should not be there in the current version of GroupShare.
Is there a reason why you are still using GroupShare 2015? I don't know whether we will resolve these things in the older versions, Phillip Maieski might be able to confirm.
we decided to split up the Studio 2019 and Groupshare migration to avoid too many "issues".
BTW on our test server with Groupshare 2017 CU9 it is also possibile to delete termbases.
And I cannot see the resolved issue in CU10, Daniel García Magariños:
Here the TB is not removed from the list but deleted completely from the server.
Hi, Bruno, you are right. I mixed the issue. I have reported the problem to SDL support, who confirmed the issue and got a CRQ number. I guess they will do the same when you report it.