AnsweredAssumed Answered

Duplicating the Read-Only Access privilege set

Question asked by brianrich46 on Sep 10, 2013
Latest reply on Sep 16, 2013 by brianrich46

I'm working with FMP11 on Windows and have over 90 legacy databases hosted on an FMP11 Server Advanced. I've been investigating if we can migrate from Filemaker Authentication to External Authentication. One major issue is that the privilege sets created for these databases have not be implemented consistently by previous developers. Although the account names used are consistent - e.g. each database has an account for ENG, SALES, QUALITY etc. - in one database the ENG account might use the privilege set 'Privilege Set 3', and in another ENG might use [Read-Only Access] - both cases giving the ENG account an appropriate level of privileges. We thought the easiest way to move to EA would be to create a new set of EA based accounts matching our current Filemaker accounts which linked directly to our Windows Security groups, and provide a parallel set of privilege sets which were copies of those used by the Filemaker Authenticated account. This would allow us to migrate users progressively by the simple expedient of adding them to the appropriate Windows Security Group when we were ready.

 

However, this didn't work where any Filemaker account used the [Read-Only Access] privilege set - any EA account linked to a duplicate of the [Read-Only Access] set kept throwing access privilege errors. It appears that duplicating the [Read-Only Access] privilege set does NOT give you a new set with the same privileges, as users of the duplicate set cannot edit global fields by default, something they can do if they are using the [Read-Only Access] set. The problem is that if [Read-Only Access] can't be duplicated to allow users to edit global fields, we'll have to edit the copy in almost every database to allow users to edit their global fields.

 

I've not been able to find a reference to this issue elsewhere, though I am told that it is 'a known issue'. Do copies of the other default privilege sets exhibit similar discrepancies? Has anybody come across this problem before, and do they have a simple solution?

 

Thanks

 

Brian

Outcomes