# Filter rows by signed in user's unique id **URL:** \ **Category:** Feature Requests\ **Created:** [November 16, 2019, 7:28pm UTC](https://community.glideapps.com/t/filter-rows-by-signed-in-users-unique-id/2054 "2019-11-16T19:28:29Z")\ **Posts on this page:** 1\ **Showing post:** 13
**Author:** ![Michael](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/michael/32/1517_2.png) [@Michael](https://community.glideapps.com/u/Michael)\ **Post date:** [November 24, 2019, 1:02pm UTC](https://community.glideapps.com/t/filter-rows-by-signed-in-users-unique-id/2054/13 "2019-11-24T13:02:28Z")
OK @Lighted_Candle, regardless of the endless debate about service providers having access to data and associated identity, the point about copying the app is interesting. I know about the fact that copying the app will duplicate the sheet and keep it private to the user. But it has 2 issues: 1- it means my users have to be Glide users, which I can’t reasonably ask from profane users 2- It breaks the possibility for me to upgrade features (and fix bugs) seamlessly. To fix #1, it would be great if Glide allowed users to log-in with their Google ID, so that it would duplicate the inner sheet to their account. It’s a feature I asked some time ago in a direct conversation with Glide developers, but I didn’t proceed with this thread. I guess I will make it a more official feature request. For fixing #2, it is possible too with he above feature proposal, **if we don’t copy the Glide app itself**. Still, a problem would remain in case the feature changes come with a change in the sheet’s structure, in which case we would need some backward compatibility mechanism, and that would get so complicate that I would refrain from asking for such a feature… Instead, I would propose that Glide prevent changing the sheet in case it was shared in “Copiable” mode (another option next to “Public with Email”, “Whitelist” etc), and if the Glide user-developer insists on doing so, there would be a warning that next users will have a duplicate branch of the app (a bit like a branch in source control), and older users will never benefit again of improvements from the new branch. Yes, I’m proposing that Glide support dev branching… Back to the debate about privacy agreement between the service provider and the user, many companies enforce a mechanism (based on user unique id) to prevent exposing the users’ private life to the developers. An app developer is not an accountant/lawyer/doctor with whom the user has explicitly agreed to share his life secrets. I’m sharing this pointer which deals more thoroughly with the identifier issue and the European GDPR regulation (which Google now complies with): [https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/what-is-personal-data/what-are-identifiers-and-related-factors/](https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/what-is-personal-data/what-are-identifiers-and-related-factors/) I just went ahead an posted the two corollary feature requests: > [@Support dev branching](https://community.glideapps.com/t/support-dev-branching/2350): > > Let’s call a cat by its name: Glide is a development framework. And as a development framework, one thing cruelly missing is source control branching. Now that I have users for my public app, I am always afraid to make changes, because they are immediately reflected in the users’ hands. The first feature I would need is a way to “stage” my changes, allowing me to change (and break) my app while making sure my changes are not published yet. And on the other way, I’d like to be able to revert m… > [@Private with Email: sheet copy per user](https://community.glideapps.com/t/private-with-email-sheet-copy-per-user/2352): > > In relation with the other [thread](https://community.glideapps.com/t/filter-rows-by-signed-in-users-unique-id/2054/13) about users’ privacy, I’ve been looking for another way to log-in to Glide apps which I would call “Private with Email”. It means that the internal sheet will be copied into the user’s private Google account, rather than being hosted in the Glide developer’s account. Yes it means that the user will have to log in using his Google ID, rather than with the Email+PIN mechanism. It would solve 2 issues: 1- the user would enjoy complete privacy with his data 2- it… --- _[View the full topic](https://community.glideapps.com/t/filter-rows-by-signed-in-users-unique-id/2054)._