I want to update my user status to be online, meaning, run this code (coffee script...)
Meteor.users.update _id: Meteor.user()._id, $set: 'profile.idle': true, 'profile.online': true if Meteor.user()?
I don't know where to put it, (is it ok to put it in client? ) where will this code run for sure with the logged in user even if user already logged in before ?
from little googling I found that meteor start events is not the place, what is the place?
client side in a Deps.autorun block would do it
in js it would be something like
Deps.autorun(function(){
if(Meteor.user()){
Meteor.users.update(Meteor.userId(),{$set:{<your fields here>}});
}
});
--
if you are trying to detect that users are online and can use meteorite, you might want to check out https://atmosphere.meteor.com/package/profile-online
you could also roll your own, by setting up a Meteor.setInterval call every 10 seconds or so to update a lastSeen time for the user, then detect if the user is online if lastSeen > timeNow - userTimeout[60 seconds?]
Related
I am currently creating a react-native app and testing it using exp on a physical Pixel 2. When I load my app up, I have the following in componentDidMount:
componentDidMount = () => {
firebase.auth().onAuthStateChanged((user)=>{
if (user) {
//this.setState({userid: user.uid}); //I added this to see if it was the below slowing things down (it is not)
firebase.database().ref('/Users/'+user.uid+'/Public/').once('value')
.catch(err=>{console.log(err)})
.then(snapshot=>{
let username = snapshot.child('Username').val();
this.setState({username: username, userid: user.uid});
});
} else {
this.setState({ user: null, username: null});
}
});}
My aim is to direct the user to the log-in page if they are not authenticated. Otherwise, dive straight into the inner pages. My code sort-of-works and this does actually take place (hurray!).
However, when I load my app up is takes a number of seconds (maybe 10 seconds), for the app to realise that I am already signed in. This means it shows the log-in page for 10 seconds and then starts to display the inner pages. Has anyone got any idea of why it takes so long for .onAuthStateChanged to register that I am in fact still signed in from my last session? And is there any way for me to know whether I am at the login page because I am not logged in at all or because the app doesn't yet realise that I am logged in? It is very awkward for the user having to sign in every time and then mid way through typing their details in, being logged in lol!
As always, all help is much appreciated.
I am not able to find more detailed docs than these. I am having issues in using status.idle. It is always false for online users even if the user is doing nothing( has been idle for more than 10mins).
I am not sure how is it diff from status.online then.
[![enter image description here][2]][2]
Here, idle is always false when user is online. I need it to be based upon the user activity.
Heres the server side code :
Meteor.publish('usersIdle', function(id){
if(this.userId){
let users = DTU.find({dTId : id}).fetch();
let dUId = _.pluck(users, 'userId');
console.log(UserStatus.connections.find({userId : {$in : doubtUsersId}, idle : false}).fetch())
return UserStatus.connections.find({userId : {$in : doubtUsersId}});
}
});
But here the 'idle' field is defined in the object.
Once you add the package, you have UserStatus object that is made available on the client side (and the server, but as an example, lets look at the client side object).
A typical scenario would be:
Once the user logs in successfully, call UserStatus.startMonitor() which will listen to key presses, mouse clicks.
Once the user logs out, call UserStatus.stopMonitor() to stop monitoring.
You then have an UserStatus.isIdle() reactive var that tells you whether that particular user is idle or not. You may use this status - for example, to log out the user. The same is also available on the server side. I'm not sure if you should explicitly write the status to Meteor.users.status.idle though.
You can check out the demo application here. It's source code is here
How can I let the user know when they are getting a hot code push?
At the moment the screen will go blank during the push, and the user will feel it's rather weird. I want to reassure them the app is updating.
Is there a hook or something which I can use?
Here's the shortest solution I've found so far that doesn't require external packages:
var ALERT_DELAY = 3000;
var needToShowAlert = true;
Reload._onMigrate(function (retry) {
if (needToShowAlert) {
console.log('going to reload in 3 seconds...');
needToShowAlert = false;
_.delay(retry, ALERT_DELAY);
return [false];
} else {
return [true];
}
});
You can just copy that into the client code of your app and change two things:
Replace the console.log with an alert modal or something informing the user that the screen is about to reload.
Replace ALERT_DELAY with some number of milliseconds that you think are appropriate for the user to read the modal from (1).
Other notes
I'd recommend watching this video on Evented Mind, which explains what's going on in a little more detail.
You can also read the comments in the reload source for further enlightenment.
I can image more complex reload logic, especially around deciding when to allow a reload. Also see this pacakge for one possible implementation.
You could send something on Meteor.startup() in your client-side code. I personally use Bert to toast messages.
I'm following this fantastic tutorial on customizing login found as the answer on this post - http://goo.gl/VLO34 - but it's not working for me.
I copied all the files verbatim, and even added supplementary smart packages such as underscore _.pick, and http Meteor.http.get just in case it was required, and mistakenly left out.
Anyhoo - I get github to authorize my app, but Meteor.users in the web console and db.users.findOne() on the local mongo instance show that Accounts.OnCreateUser() didn't add any new information to my user profile [that I'm pulling in from github]. In other words, {{currentUser.profile.avatar_url}} and {{currentUser.profile.login}} won't reveal anything following that tutorial. So I get blank info on the screen.
I tried that screencasts first attempt, and noticed that {loginButtons}} returns values for {{currentUser.profile.login}}. I've reviewed the code many times for typos, but feel that something is quite off with Accounts.onCreateUser(fn)...
I'm using Meteor 0.5.7, and if anyone else has experienced this problem following that screencast, please let me know. Thanks,
EDIT: I've deployed the project to - http://rptest-customlogin.meteor.com/.
Author of the screencast here. And as of a few seconds ago, a new user on your site :-). So, it looks like login is working on your site. But I'm guessing what's happening in your app is the login info isn't available yet at the time of rendering or at the time you're printing to the console. The reason is that all of that info is being populated asynchronously. It takes a few seconds for the process to complete. If you're relying on Meteor.user().profile data in your templates you need to check first if the login process is still underway.
To do that, you can use either the Meteor.loggingIn() javascript function or the {{#if loggingIn}} handlebars block helper. That function is "reactive" which means once the result changes from true to false your UI will update. So the template might look something like this:
<template name="loginDependentWidget">
{{#if loggingIn}}
Logging In
{{else}}
{{currentUser.profile.avatar_url}}
{{/if}}
</template>
Does this help?
Might be a typo but Accounts.OnCreateUser(fn); should be Accounts.onCreateUser(fn);
Meteor docs: http://docs.meteor.com/#accounts_oncreateuser
And then another post on the same subject:
Meteor login with external service: how to get profile information?
EDIT:
Posting as edit due the formatting of the below piece of code.
In the meantime I have got it running on my own project with this piece of code:
Accounts.onCreateUser(function(options, user) {
if(!options || !user) {
console.log('error creating user');
return;
} else {
if(options.profile) {
user.profile = options.profile;
}
}
return user;
});
Which is working just fine. Have you placed the Accounts.onCreateUser(); on the server?
I am using Meteor 4.2 (Windows) and I am always getting the "update failed: 403 -- Access denied. Can't replace document in restricted collection" when I am trying to update an object in my collection. Strangely I had no problem inserting new ones, only updates are failing.
I tried to "allow" everything on my collection:
Maps.allow({
insert: function () { return true; },
update: function () { return true; },
remove: function () { return true; },
fetch: function () { return true; }
});
But still, this update fails:
Maps.update({
_id: Session.get('current_map')
}, {
name: $('#newMapName').val()
});
Is there something else I can check? Or maybe my code is wrong? Last time I played with my project was with a previous version of Meteor (< 4.0).
Thanks for your help.
PS: Just for information, when I do this update, the local collection is updated, I can see the changes in the UI. Then very quickly it is reverted along with the error message, as the changes has been rejected by the server-side.
Alright, the syntax was actually incorrect. I don't understand really why as it was working well before, but anyway, here is the code that works fine:
Maps.update({
Session.get('current_map')
}, {
$set: {
name: $('#newMapName').val()
}
});
It seems like it must be related to what you're storing in the 'current_map' session variable. If it's a db object, then it probably looks like {_id:<mongo id here>} which would make the update finder work properly.
I ran into the same issues, and found the following to work
Blocks.update {_id:block_id}, {$set: params}
where params is a hash of all the bits i'd like to update and block_id is the mongo object id of the Block i'm trying to update.
Your note about the client side update (which flashes the update and then reverts) is expected behavior. If you check out their docs under the Data and Security section:
Meteor has a cute trick, though. When a client issues a write to the server, it also updates its local cache immediately, without waiting for the server's response. This means the screen will redraw right away. If the server accepted the update — what ought to happen most of the time in a properly behaving client — then the client got a jump on the change and didn't have to wait for the round trip to update its own screen. If the server rejects the change, Meteor patches up the client's cache with the server's result.