[Swiss1000]

I can certainly look into adding an option to keep login information separate per library. It would be disabled by default as that could be annoying for users with multiple libraries but only a single account. The other things are planned and should be addressed soon.

Sorry I wasn't attentiv to this : " MSP remembering which google drive account is linked to which library "

This is absurd from a computer and security perspective: the directory should be backed up by the directory, or shared directory, not the account. 

Everyone has their own Drive account, or whatever, and it's personal. A main account (Drive) includes a "Shared Directory."  This gives access to a directory containing files from other accounts, shared by the owners of those accounts. It's universal and logical. You think of these shares as personal folders, but they're temporary; the owner remains the owner.

If you remember the destination, as long as it's shared, you can write to it.

Let's take an example: Jazzy Boomers and Bowling Blues are two bands. Each has a directory for sheet music and shared files. 
Each musician has their own personal Drive account. 

If you have a new musician, you can provide them with a link or a shared part, depending on the band they belong to. 

When the musician leaves the band, you remove his access (adress) to the shared directory.
If the account is shared, they will have and keep full access, which you can't simply remove. 
This isn't what you want, and you have to change the password to remove access, which affects everyone have the same strategy and account memorized... 

You don't need to go beyond network logic to satisfy every request. You need to remember the access path only, in speparate librairy, and the PERSONAL account information, in global parameters.

I am campaigning for Mobilesheets to become a more effective tool for conducting, and we need to be careful about that.

[mdavej]

@Swiss1000, the band member whose access you removed already got local copies of everything. Seems like a massive security hole if you ask me, and one with no solution.

[Jazzy Boomers]

@Swiss1000, the band member whose access you removed already got local copies of everything. Seems like a massive security hole if you ask me, and one with no solution.

It's no more important than a paper copy of a performance. But it does prevent a temporary musician from learning all the new arrangements.

[maks261]

For me personally - as i described in the beginning - this security topic is not a problem.
I am accessing my dad's drive as well as my own, we're too close to each other to ever consider this a security hole.

I get the point that once you start sharing your library with someone else there is going to be a security risk - but finding a proper solution for THAT sounds like it is going to be 1000x more complex than what i described (just remembering the google drive account per library, as Mike said, optionally enabled), if feasible at all. And as mdavej already said, once someone got the copy of library you cannot revoke access to it afterwards anymore anyhow.

[Swiss1000]

For me personally - as i described in the beginning - this security topic is not a problem.
I am accessing my dad's drive as well as my own, we're too close to each other to ever consider this a security hole.
I get the point that once you start sharing your library with someone else there is going to be a security risk - but finding a proper solution for THAT sounds like it is going to be 1000x more complex than what i described (just remembering the google drive account per library, as Mike said, optionally enabled), if feasible at all. And as mdavej already said, once someone got the copy of library you cannot revoke access to it afterwards anymore anyhow.

Sharing a folder in Drive isn't complicated! It's a basic feature used by millions of people and a method used by ALL network administrators. 
If Mobile Sheet were to break this rule to accommodate a request, it would be truly absurd.

I think you don't understand the scope of your solution and that it's detrimental. Remembering one path per library solves your problem.

[maks261]

For me personally - as i described in the beginning - this security topic is not a problem.
I am accessing my dad's drive as well as my own, we're too close to each other to ever consider this a security hole.
I get the point that once you start sharing your library with someone else there is going to be a security risk - but finding a proper solution for THAT sounds like it is going to be 1000x more complex than what i described (just remembering the google drive account per library, as Mike said, optionally enabled), if feasible at all. And as mdavej already said, once someone got the copy of library you cannot revoke access to it afterwards anymore anyhow.

Sharing a folder in Drive isn't complicated! It's a basic feature used by millions of people and a method used by ALL network administrators. 
If Mobile Sheet were to break this rule to accommodate a request, it would be truly absurd.

I think you don't understand the scope of your solution and that it's detrimental. Remembering one path per library solves your problem.

Never claimed it was complicated. I'm a software developer myself btw, i have my fair share of related knowledge.

Back to topic - just imagine having 2 music projects, each with their own domain, linked mail and therefore also separate gdrive accounts. Doesn't even have to be different real people but could still result in similar requirements.

I don't get why u are bothered by Mike introducing a gdrive account memo feature - if you keep your 1 almighty account linked it wont even affect you.
If you want the gdrive folder path memo feature you suggested, that could be added as well (!) - they're not mutually exclusive - and in the end of course up to Mike, which features he wants to implement and which not.

But stop calling my requests absurd, detrimental, etc. - thanks.

[Zubersoft]

I'm also not sure why Swiss1000 is saying I would be breaking a rule by saving different account information per library. A library is just a separate database on the device. It has nothing to do with separate users, however, there is no downside that I see to allowing a user to have different accounts associated with a particular library for users that need this. This would also be disabled by default for users that want to use the same account for every library. If you export settings or backup a library, this saved account information is not contained in any of the generated files as you wouldn't want another using logging in with your accounts.

Mike

[Swiss1000]

I'm also not sure why Swiss1000 is saying I would be breaking a rule by saving different account information per library. A library is just a separate database on the device. It has nothing to do with separate users, however, there is no downside that I see to allowing a user to have different accounts associated with a particular library for users that need this. This would also be disabled by default for users that want to use the same account for every library. If you export settings or backup a library, this saved account information is not contained in any of the generated files as you wouldn't want another using logging in with your accounts.

Mike

It's unethical to offer a solution for storing passwords outside of a secure database. It's better to keep the path; if the user has access, fine; if not, it's denied. Once you've "encouraged" bad behavior like sharing a password, you become a bad partner, and what's more, you create problems you don't manage. There shouldn't be more than one user in a million asking to keep their dad's passwords... That's immature. The "drives" (all of them) have a sharing procedure, which can be revoked without providing a password. You can look for explanations, but it's not professional; it's meant to please, but it's risky.

[Zubersoft]

You think I'm storing passwords? I would never do that. I store an oauth2 token, and for some cloud services the account name that was used (as it's needed for some services like Google Drive), and that is it. That's also stored in the preference files (hidden from user access) and not included with backups or exported settings, as mentioned. There is literally no way for users to get access to that information unless they rooted their device, and even then, they are just getting an account name which is relatively useless by itself. Oauth2 tokens also expire after short while and have to be refreshed. This is all happening through each company's SDK, so I'm not even the one handling the oauth2 stuff.

Mike

[Swiss1000]

You think I'm storing passwords? I would never do that. I store an oauth2 token, and for some cloud services the account name that was used (as it's needed for some services like Google Drive), and that is it. That's also stored in the preference files (hidden from user access) and not included with backups or exported settings, as mentioned. There is literally no way for users to get access to that information unless they rooted their device, and even then, they are just getting an account name which is relatively useless by itself. Oauth2 tokens also expire after short while and have to be refreshed. This is all happening through each company's SDK, so I'm not even the one handling the oauth2 stuff.
Mike

Ok If you want to satisfy "papa connexion"  

I share a directory in Google Drive for musicians. No shared accounts, no personal information. If the directory is shared, people have access to it; otherwise, just store the path in the library. Multiple groups, each with their own access path, see nothing else. With shared access, they see everything, including advertising or commercial information. Don't invent the wheel for a story about trusting your father...

[itsme]

It's not your job to tell Mike how to run his business.