So the requirement is to create a Subscribe & Unsubscribe button on Queue. The issue is that the user's responsibility of working on a task assigned to a Queue varies from 1 week to a month and then it is handed over to the other user to work. The problem is that currently the users has to go on a the task queue list view to see if there is any new task assigned but this unnecessarily wastes their time. I created a solution but that gives the notification only when the user is a member of that Queue but as mentioned above this membership might change quick quickly and they think asking the admin to change the queue membership could be quite overwhelming for them and the admin as well. Unfortunately, the admin cant give the customisation access of Queues to the users. So what could be right solution for this?
I am implementing the functionality where user can withdraw money from their account via PayPal.
The problem is that I can't wrap these actions into a transaction, since one of them is a call to an external service (PayPal).
Could you please suggest how to make it atomically to avoid data inconsistency issues?
I have a google service account setup for their calendar api, but it seems as though I can only make 5 requests per second. I've only figured that out from trial and error, there are no per second rate limit settings on my developer console settings.
I have 'queries per day' and 'queries per 100 seconds per user', both of which are currently set to 1,000,000.
I'm definitely not hitting these limits, so I can only assume there is a hidden 'per second' rate limit that is being applied. Does anyone know if that is the case?
Thanks!
I think this documentation will help you to understand more the Calendar usage limits.
Google Calendar puts certain limits in place to protect our users and infrastructure from abusive behavior. When these limits are reached by a user, Google Calendar will go into read-only mode for that user, and all edit actions will fail for a certain period of time. Most users will never hit these limits, as they are well above the activity level of a typical Calendar user.
I'd also like to add a few tips to work efficiently with your quota:
Use push notifications instead of polling.
If you cannot avoid polling, make sure you only poll when necessary (for example poll very seldomly at night).
Use incremental synchronization with sync tokens for all collections instead of repeatedly retrieving all the entries.
Increase page size to retrieve more data at once by using the maxResults parameter.
Update events when they change, avoid re-creating all the events on every sync.
Use exponential backoff for error retries.
Check the performance tips of the Calendar API
I want to know what will happen to the users of my app that I used anonymous sign in method for them.
The Firebase documentation is really BAD and didn't explain everything and expect developer to find out himself.
I found in its old version documentation that anonymous session will expires based on the expiration time has been set in Login & Auth tab, but even there didn't mention this means just the session ends or it means that user id will remove also from my app users list or what EXACTLY happened?
I found this answer but it really is not acceptable. The number of anonymous users will grow very very fast if you do a web app and make every thing hard.
I even cannot see the number of my app users in my dashboard!!!!!
So, what should i do? should i develop a dashboard for my data myself or Firebase team should do it? At least for managing users i should have more power than just searching user with their email and when you use custom login you cannot do this also.
Anonymous users don't expire, and there isn't currently any automated way to purge them.
Firebase doesn't automatically remove them because it doesn't really know if a user is still storing data linked to that login - only the app creator does. Imagine if you are playing a puzzle game on your phone, and get to level 100. Then when you go to play level 101 next year, all progress is lost. Firebase can't just assume a user being inactive for a year means that the account can be removed.
There is a couple tools that should help, though.
1) Admin SDK & Firebase CLI list users.
2) Linking multiple auth providers
3) Auth State Persistence
Once you list your users, you can check that each doesn't have any other providers, and hasn't been used recently, doesn't have data stored, and delete them.
Better, though, would be to ensure that only one account is created per user. If you create an anonymous account to help users store data before logging in, you may want to consider prompting them to link a auth provider (like Google or email). If you link the account, rather than creating a new one, you'll avoid abandoned accounts from active users.
In general, you will also want to make sure to use auth state persistence to ensure that there aren't more accounts than necessary being created. Creating 1 account per new visitor, rather than 1 per time someone repeatedly visits your page, will significantly help keep user growth in check.
In my case, I am using the anonymous sign-in method for authentication without the knowledge of the user.
Each time when the user leaves the app, delete the anonymous user by -
FirebaseAuth.getinstance().currentuser?.delete()
There will be no stacking up of anonymous user with this and limits the number of anonymous user in the app
2023 update
Firebase has automatic clean up now.
If you've upgraded your project to Firebase
Authentication with Identity Platform, you can enable automatic
clean-up in the Firebase console. When you enable this feature you
allow, Firebase to automatically delete anonymous accounts older than
30 days. In projects with automatic clean-up enabled, anonymous
authentication will not count toward usage limits or billing quotas.
Any anonymous accounts created after enabling automatic clean-up might
be automatically deleted any time after 30 days post-creation.
Anonymous accounts created before enabling automatic clean-up will be
eligible for automatic deletion starting 30 days after enabling
automatic clean-up. If you turn automatic clean-up off, any anonymous
accounts scheduled to be deleted will remain scheduled to be deleted.
These accounts do not count toward usage limits or billing quotas. If
you "upgrade" an anonymous account by linking it to any sign-in
method, the account will not get automatically deleted. If you want to
see how many users will be affected before you enable this feature,
and you've upgraded your project to Firebase Authentication with
Identity Platform, you can filter by is_anon in Cloud Logging.
Docs
There is a possible cloud function for that.
Check: delete-unused-accounts-cron
This function deletes unused accounts after a certain time. Which might be also helpfull for nonanonymous users.
If you only want to delete anonymous users or check only for them (for example delete after a different inactive time than normal users) you can identify them by checking:
const inactiveUsers = result.users.filter(
user => {
isAnonymous = user.providerData.length == 0;
//do something when anonymous
});
If you'd like anonymous users to be removed from your user list, you'll have to write a service to do that for you.
Since firebase doesn't provide a way to list registered users, you'll have to make sure you're storing some sort of user list in the database. You can then use the node.js admin sdk to get user data, check if the user is anonymous, and find when the user was created. For performance reasons, you may wish to store this information in a special area of your database and retrieve it all at once. Once you've identified a stale anonymous user they can be easily deleted.
I need to prevent all CRM Online users from logging in for a short period time while I perform an upgrade to some of the customizations.
Disabling each user is time consuming and I believe that disabling will require a new "invitation" after the user is re-enabled.
What is the best approach for this?
I would suggest trying to disable the Business Unit. But you cannot do this if you only have one Business Unit defined.
http://rc.crm.dynamics.com/rc/2011/en-us/online/5.0/Help/source_set_BU_EnableDisable.htm
According to the online documentation above, disabling the BU will disable login for all users.
We would have to deduce a suitable methodology for managing this, for instance having a single user in a second “administrative” BU that you would login as that user to manage this process.