I'm working on a project where I have to handle unregistered user - users that have been added to the group but still they do not have registered in the app.
What I'm doing now is to create a new child in my 'user' db, putting all the info that i know about this unregistered user.
Of course, it also has an id.
This id will be used to represent that user and so it will be used in a lot of places of the db.
The problem comes when this user tries to register itself. Since when creating a new user it's not possible to force the 'id' that he already had, Firebase will create a new id for him.
Then, in the db I need to change all the references of the 'old id' with the new one.
Is there any better way to do it ?
1) You can use another "fake" table to remap the IDs, that is, instead of changing the old id and its references you can add new instance to your "fake" table when user registered. And when needed using simple service you can find the corresponding id.
2) Secondly, you can do authentication yourself, what I mean is that, you can develop your own registration service and define the id yourself in registration. If system is already big and hard to change. First option would be suitable but will have some cost in terms of time.
Related
I like to include the entities in the paths generated by ApiPlatform.
In practice, I want the build URL contains the IDs of the "parent" entities, the ones to which belong the entity I'm retrieving.
As in the object, I'd like URLs like those:
/{account_id}/channels: here the Channel entity has a property Account $account with a many-to-one relation (one Channel can have only one Account but one Account can have multiple Channels)
/{account_id}/{channel_id}/another_entity: here I want to retrieve AnotherEntity that have property Channel $channel (it may have also the property Account $account, but it may not have it).
How to build those URLs?
The idea is to permit the User to have multiple tabs open with different accounts, without force him/her to see one account a time: I want the User be able to open at the same type Account 1 and Account 2.
Ideally, on each {account_id} should be a check that confirms the User has access to the Account in the URL (starting from its ID).
I am doing the user authentication where I have this case:
Read from vendor_type document and if it returns null(doesn't exist) then continue the transaction,
Create new user using .auth().createUserWithEmailAndPassword(email,password),
Read the new users ID,
Write to vendor_type document some of the new user's detail such as name, surname, userId -->> userId is the problem, how can I create a user and get the ID within a single transaction, can I even do that? ,
Take the newly created ID of the user, and create a new vendor document with that ID.
So far I don't have any code to post because I don't know if this is even gonna work so I didn't start. If you have any idea how to implement this, please let me know. The main issue is getting the user ID while still in the transaction.
At the time of writing, it is not possible to combine in one transaction the creation of a user through the createUserWithEmailAndPassword() method from the Auth service AND a write to the Firestore service.
They are two different services offered by Firestore and therefore you cannot combined calls to these two different services in one transaction.
Am looking at the data structure in this post and want to know how you would go about getting the emails of users who belong to a certain group when they could belong to several groups and the GroupID stored against that user is the current group they are participating in?
Do you store the email addresses with the userid under the "members" or, instead, for each member of the group, get that user's email address from the "users" document userid (this would mean iterating through the group/members collection and doing a query for each user. Not very efficient).
Am used to SQL so this is all new to me.
You should have a single node for each user
/users/UID/emails/
/users/UID/emailunread/
/users/UID/settings/
/users/UID/details/
/users/UID/payments/
So you can simply do a subscription for a singular node path this.myDatasubscription = this.DB.list('users/' + this.uid).snapshotChanges() ensuring changes like new emails or account settings will detected and rolled out in real time back to the app, so your are using angular/ng or something similar client side then your variables {{this.email_list}} should update real time with no page changes.
Take a look at this one.
error: Property 'getChildren' does not exist on type 'DataSnapshot'
Someone know any way to prevent the possibility of adding new record from lookup field?
I want that the users be able to choose only created records. but they couldn't create new from the lookUp.
thanks!
You need to create a security role for your users defining the permissions you want them to have. You will need to have CREATE permission turned off on the lookup entity you don't want them to create.
One source with further information about Security Roles is here:
http://crmbook.powerobjects.com/system-administration/business-administration/security-roles/
I've tried searching this for days and can't seem to find an adequate answer so I'll ask here.
I'm building an asp.net Membership website.
What I want to do is:
Allow a user to create an account - say UserA
I then want to allow UserA to create "sub accounts" tied into his account, but with different roles as well as different login names (I'll be using email address as the login name)
UserA would be the account admin of sorts.
UserA's sub accounts would be less "adminish" than UserA, but any data that they write to my DB (Entity Framework) would still be tied to the main UserA account which will be referenced to my tables via Membership.GetUser() API calls.
So 2 questions:
1) How would I reference the Membership tables in my EntityDataModel using DB First (I already ran the aspnet_regsql.exe)
2) How would I need to go about allowing UserA to create his own sub users?
Here's an image of my custom tables:
[MasterAccountUser]
MasterAccountId = aspnet_Membership.UserId
AccountNumber = autoincrement number
[UserAccount] - subaccount of [MasterUserAccount]
AccountId = aspnet_Membership.UserId (if I have to have each user create their own)
MasterAccountId = aspnet_Membership.UserId (but the same one as the [MasterAccountUser]
If this is too vague, let me know and I can expand.
I was able to get this to work.
Basically, you just do the standard aspnetdb.mdf with all the in-place security features.
Then you simply add a table with the same fields, and then you reference the
MembershipUser.GetUser(Page.User.Identity.Name);
So you own table will have a "masteruser" with this User.ProviderKey. Every "sub-user" then has the SAME masteruser guid on their record so that they all fall under the same account.
If anyone want more details on how i got this to work, i can happily provide them.