PM Read Receipts Version 2.0

[Quozzo]

Sept 1, 2015 20:41:27 GMT -8 P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ said:

Sept 1, 2015 20:31:36 GMT -8 Quozzo said:

Yeah its cool. The only thing I would want really want changing is who read the PM before the latest reply. The easy work around is only to send it to one person, because even if they reply, it still records them viewing it. I wouldn't want to mess around with the design too much because I can see how it can be useful, I just prefer the other method I described.

What about this: If it recorded the time it was viewed by each user then it would be possible to determine who viewed which message. Key data by a user would mean they have viewed the original message, you could easily determine what was the last message they viewed by comparing the time stored in the key to the time on each message. It would be possible to put a small notice in the convo stating what messages certain users had read.

The other suggestions were only aesthetics really. I seen the other thread and I think this is a great work around (although I do believe an exception should be made by ProBoards to preserve the users experience but I digress). There are bound to be a few bugs and a few opposing ideas on how it should function, but that's what this board is for

Keep it up.

I was already going to start recording time.
Use that to create a bar on last viewed showing when someone stopped is a neat friggen idea. 
The only problem with this whole data concept is stale key data. 
If a user was in the middle of a message, ate some supper, came back in a couple hours, wrote and posted.
This would overwrite all views, last seen timestamps, and original message view status (if multiple users).

How would you suggest combating that problem? 

You could always push the latest data to the key, the ID and timestamp of the user posting. I believe that doesn't overwrite the entire key but just appends the data server side. How you would remove the old data though is a bit tricky as it will pile up. It needs to be a user initiated action so removing any old duplicate ID and timestamps when then user clicks to read the PM would be possible. It would only be 60s old at most.

• When a PM is clicked, the page changes and you get new key data. When the user clicks to read the PM within 60s, any duplicate ID's that are older are removed and the key is updated, along with the ID and timestamp of the user who has just opened the PM.
• Viewing the PM compares each timestamp in each individual message with that of the timestamp for each ID recorded. Any message timestamps that are greater than in the key are newer, and the user has not read those.
• When a user posts a reply, their ID and timestamp are pushed to the key, so the key is untouched but has a new data appended. The timestamp i

With this idea though, it won't be possible to determine when a user is viewing the PM with a new message they haven't seen, which would prompt the popup box. The only thing I can think of is to always show the popup which when clicked, would always update the key and remove any duplicate ID's if there are any.

You could even list all users on the conversation page who have read the PM at some point in chronological order, with the date string in the title attribute so hovering over it would display exactly what time they viewed it.

A bit convoluted, but that's how I would do it anyhow.

Edit: Oh and thanks for the badge! Really appreciate it 

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Sept 2, 2015 9:07:30 GMT -8 Quozzo said:

Sept 1, 2015 20:41:27 GMT -8 P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ said:

I was already going to start recording time.
Use that to create a bar on last viewed showing when someone stopped is a neat friggen idea. 
The only problem with this whole data concept is stale key data. 
If a user was in the middle of a message, ate some supper, came back in a couple hours, wrote and posted.
This would overwrite all views, last seen timestamps, and original message view status (if multiple users).

How would you suggest combating that problem? 

You could always push the latest data to the key, the ID and timestamp of the user posting. I believe that doesn't overwrite the entire key but just appends the data server side. How you would remove the old data though is a bit tricky as it will pile up. It needs to be a user initiated action so removing any old duplicate ID and timestamps when then user clicks to read the PM would be possible. It would only be 60s old at most.

• When a PM is clicked, the page changes and you get new key data. When the user clicks to read the PM within 60s, any duplicate ID's that are older are removed and the key is updated, along with the ID and timestamp of the user who has just opened the PM.
• Viewing the PM compares each timestamp in each individual message with that of the timestamp for each ID recorded. Any message timestamps that are greater than in the key are newer, and the user has not read those.
• When a user posts a reply, their ID and timestamp are pushed to the key, so the key is untouched but has a new data appended. The timestamp i

With this idea though, it won't be possible to determine when a user is viewing the PM with a new message they haven't seen, which would prompt the popup box. The only thing I can think of is to always show the popup which when clicked, would always update the key and remove any duplicate ID's if there are any.

You could even list all users on the conversation page who have read the PM at some point in chronological order, with the date string in the title attribute so hovering over it would display exactly what time they viewed it.

A bit convoluted, but that's how I would do it anyhow.

Edit: Oh and thanks for the badge! Really appreciate it 

When a user posts a reply, their ID and timestamp are pushed to the key, so the key is untouched but has a new data appended. The timestamp i
That's the problem, the only way to save to a key on a post button is using set_on
Pushing on post and quick reply currently is against TOS.
Not to mention if I use set (anywhere) in the plugin, the push's can still be overwritten. If there was a push_on command, I would have done this entire plugin with push and wouldn't have to put timers on anything.

[Quozzo]

Sept 2, 2015 9:38:22 GMT -8 P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ said:

That's the problem, the only way to save to a key on a post button is using set_on
Pushing on post and quick reply currently is against TOS.

Are you sure about that? Posting a message would be a user initiated action. I thought that using set_on would only apply after the page had refreshed, and would effectively be setting it on a new page after a new thread or new post had been made (so the thread/post id would be available.) Using push as a new message is created would use less bandwidth than using set_on.

I'll see if Brian can give us some insight into using push on message submission.

If not then there's a good chance that stale key data will be a major problem and your original method would likely be best.

[Brian]

There are currently no set_on events that are not duplicates of the set function, so for the time being it's not possible to push to a key upon post submission as P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ said since at the moment you can only overwrite it entirely.

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Sept 2, 2015 13:04:30 GMT -8 Quozzo said:

Sept 2, 2015 9:38:22 GMT -8 P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ said:

That's the problem, the only way to save to a key on a post button is using set_on
Pushing on post and quick reply currently is against TOS.

Are you sure about that? Posting a message would be a user initiated action. I thought that using set_on would only apply after the page had refreshed, and would effectively be setting it on a new page after a new thread or new post had been made (so the thread/post id would be available.) Using push as a new message is created would use less bandwidth than using set_on.

I'll see if Brian can give us some insight into using push on message submission.

If not then there's a good chance that stale key data will be a major problem and your original method would likely be best.

support.proboards.com/post/6319142
Me and Todge had this discussion already when this plugin was conceived. 
That was the final verdict of what we wished to propose. 

[Quozzo]

Sept 2, 2015 13:14:12 GMT -8 Brian said:

There are currently no set_on events that are not duplicates of the set function, so for the time being it's not possible to push to a key upon post submission as P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ said since at the moment you can only overwrite it entirely.

Using set_on. But would it be against TOS to push data to a key upon submission?

[Brian]

Sept 2, 2015 14:23:22 GMT -8 Quozzo said:

Sept 2, 2015 13:14:12 GMT -8 Brian said:

There are currently no set_on events that are not duplicates of the set function, so for the time being it's not possible to push to a key upon post submission as P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ said since at the moment you can only overwrite it entirely.

Using set_on. But would it be against TOS to push data to a key upon submission?

Not against the TOS, but you'd be halting the post submission process to set a plugin key which goes against our policy of running a set request under circumstances that the user would expect.

The user expects the submit button to submit the post rather than stall the page for a moment and submit their post after the stall (since halting the submission process is the only way to ensure the AJAX request finishes).

Until an event similar to set_on exists for the other functions it won't be possible to push to a key upon post submission.

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Thanks Brian for explaining it a little better than the post does.

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Sept 2, 2015 13:04:30 GMT -8 Quozzo said:

Sept 2, 2015 9:38:22 GMT -8 P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓ said:

That's the problem, the only way to save to a key on a post button is using set_on
Pushing on post and quick reply currently is against TOS.

Are you sure about that? Posting a message would be a user initiated action. I thought that using set_on would only apply after the page had refreshed, and would effectively be setting it on a new page after a new thread or new post had been made (so the thread/post id would be available.) Using push as a new message is created would use less bandwidth than using set_on.

I'll see if Brian can give us some insight into using push on message submission.

If not then there's a good chance that stale key data will be a major problem and your original method would likely be best.

Version 1.2 is out if you want to see progress and that bugfix. Also notes additions on first post in a separate block.

[flateric5456]

Ok a question from the thickie I have installed the plugin and nothing has happened I must be doing something or not doing something, do I have to activate it elsewhere in some other part of the forum

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Sept 3, 2015 9:12:34 GMT -8 flateric5456 said:

Ok a question from the thickie I have installed the plugin and nothing has happened I must be doing something or not doing something, do I have to activate it elsewhere in some other part of the forum

I guess my question is "Did you open an inbox message?"

[flateric5456]

I did I have sent messages and received them ........ sadly nothing

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Sept 3, 2015 12:29:52 GMT -8 flateric5456 said:

I did I have sent messages and received them ........ sadly nothing

If nothing is happening I will have to take a look at your forum. It could be theme related or an oversight of mine. 
What's your link?

[flateric5456]

trade-support.freeforums.net/

[P̌̓aͧś̀t̀u͒le͆o͂2̀3̃̓]

Sept 3, 2015 13:33:19 GMT -8 flateric5456 said:

http//trade-support.freeforums.net/

This is a screenshot of a new account that seems to be working properly.
This is using the browser google chrome.
Are you using safari, firefox, Internet Explorer 10, or 11?