Getting 'New Thread' ID

[Todge]

Is it possible to find out a thread ID BEFORE it is created?

As in, from the new_thread page, is it possible to find out what the thread ID will be BEFORE the Create Thread button clicked?

[Wormopolis]

not that I have found. it doesnt get assigned until the POST gets sent, thats why the key API has set_on commands.

I could be wrong though...

[Todge]

That's what I assumed too, hence this question.

I'm trying to use the set_on command to set a super forum key, and I need to add the new thread's ID to it, hence the question. As new threads are 'ID'd' incrementally I could use the key to keep track of new threads and update automatically, but that's asking for trouble, and I'd rather not add another mouse click to set it.

[Wormopolis]

sending a PM

[Tim Camara]

Mar 9, 2014 1:04:49 GMT -8 Wormopolis said:

not that I have found. it doesnt get assigned until the POST gets sent, thats why the key API has set_on commands.

Wormopolis is correct, we don't assign the ID until the thread/post/etc. is created.  I'm assuming you're trying to use the not-yet-created ID as part of a key rather than by itself, so I see how using set_on may not be a viable option.  I went ahead and added a task to our system to look into various ways of incorporating better functionality into the set_on hooks, to provide greater flexibility in these situations.

(Also, if you have any ideas on implementation, leave 'em here for consideration, currently I'm thinking passing in an anonymous function and a key to a set_on call)

[Todge]

Yup, I would like to write the new thread's ID to the key when the thread is created. Which I obviously can't do.

Having the latest thread ID in pb.data may not help either, as threads could be created while you're looking at the thread creation page. Would it be possible to have a kind of 'set_after' type thing, to set the key directly after the thread has been created instead?

[Tim Camara]

Would something like this work?

pb.plugin.key('test_key').set_after(hook, action, [object_id], [value]);
where:
- hook is the same as the set_on hook (e.g., the form that's being submitted)
- action is one of the existing key operations (push, pop, shift, unshift, increment, decrement, append, prepend, set)
- object_id is an optional param that specifies the key's ID (would use the newly created item's ID if it doesn't exist)
- value is an optional param that specifies the value to use in the action (would use the newly created item's ID if it doesn't exist)

It obviously still has some limitations, but other than giving people access to execute code on the server (which just isn't happening), I can't see a way to make it more flexible than this.

[Peter]

Tim Camara,

I think that's fine. I just appreciate that you are even implementing some of these things for us, as it opens up doors for new plugin ideas.

[Todge]

That looks good to me too.

So, using that syntax..

pb.plugin.key('test_key').set_after('thread_new', 'push', pb.data('route').params.thread_id);

should add the new thread ID to the current plugin's content, yes?

[Tim Camara]

Yeah, that would do it. Although in thinking about it, I would probably make the input to the set_after action a hash rather than hardcode the options, that way it's easy to specify a value without specifying an object_id.

[Wormopolis]

is there an update on where on the list "set_on_edit" lies? to refresh your memory, that was the method to update a key on a post/profile edit to overcome the webkit bug of not allowing AJAX to happen when a form was submitted.

[Tim Camara]

Okay, it took me way too long to remember what that was. That'll most likely happen at the same time as we implement the set_after function. The list of requests for plugin and key related functionality is quite long at this point, but those are (I think) about third in line, under making plugins run on error pages and the function to pull specific member data. As for where it falls in the overall list, that's a bit harder to say. Obviously the majority of our time is being spent on the big secret new project, so new feature development has slowed to a bit of a crawl. That being said, I'm personally anxious to get back to fixing up the plugin and library stuff, so I wouldn't expect it to be too much longer.

[Lynx]

I just came across this old thread - so my apologies for necro'ing a 6-year old thread ... but, was set_after ever implemented, or is it something that will (hopefully) come with V6?

[Todge]

Sept 2, 2020 18:41:40 GMT -8 Lynx said:

I just came across this old thread - so my apologies for necro'ing a 6-year old thread ... but, was set_after ever implemented, or is it something that will (hopefully) come with V6?

Fingers crossed, it will be included with the V6 updtate, unfortunately I never heard anything about the set_after function after this, so I assume it was never implemented.

[Lynx]

Sept 3, 2020 3:47:29 GMT -8 Todge said:

Sept 2, 2020 18:41:40 GMT -8 Lynx said:

I just came across this old thread - so my apologies for necro'ing a 6-year old thread ... but, was set_after ever implemented, or is it something that will (hopefully) come with V6?

Fingers crossed, it will be included with the V6 updtate, unfortunately I never heard anything about the set_after function after this, so I assume it was never implemented.

Thanks for the reply, Todge!

Maybe I can give Matej a nudge and see if they know.