I'm using Slack's modals + their new BlockKit interactive actions. I have a modal dialog with several section's that include select menu accessories. When one of those accessories changes (ex: user preference goes from Yes -> No), I want to update the modal's view to reflect the change in some contextual text.
The docs outline two ways to update a model. Because I'm not using the traditional modal inputs, I have to update the modal via the API and not via response_action. Proof: I don't even receive a view_submission payload at all... I receive a blockkit_action payload.
The docs conflict a bit. In the above link they say that to update a view you must pass in the returned ID of the view when it was opened:
Remember the view.id that was included in the success response when
you used views.open earlier? We hope you kept it, because you can now
use it to update that view.
But when you look at the docs for the views.open and views.update, it appears there is a second option: external_id. The views.update docs say this:
A unique identifier of the view set by the developer. Must be unique
for all views on a team. Max length of 255 characters. Either view_id
or external_id is required.
Initially I got everything working really nicely by choosing an external ID of myapp-mymodal-[userID]. But as soon as I tried opening the modal simultaneously on my Desktop + Mobile client, I started getting internal_error responses and have been unable to open the modal since!
So I started looking into saving the view ID, per the first quote. My problem is: that ID changes every time the modal opens. I don't understand how I am expected to possibly keep track of the 0-2 "active" view IDs that might be taking place across a user's Desktop + Mobile clients (or more than 2 if they have an iPad, a second laptop, etc).
I tried to look for some sort of unique client ID that I could either use to include in the external_id or in my view_id persistence logic, but given that Slack's API appears to be sesssion-less I couldn't find any such thing.
How do others solve this problem?
Try using the private_metadata field in the View
I initially did the same thing you did, which worked, but I wanted to avoid that edge case if possible. What I figured out, is that I could pass the external_id that I created when opening the view into the view's metadata, and then retrieve it when I receive an interaction.
When I set the external_id I set it to the userID + the current time (so it's always unique, even if the user opens the modal from different devices)
externalID := UserID + time.Now().String()
and pass that both as the external_id for the view, and as a string into the private_metadata.
PrivateMetadata string `json:"private_metadata"`
When the user interacts with one of my blocks and Slack sends me the interactive message, I retrieve the metadata like this:
Request.Payload.View.PrivateMetadata
I wrote my Slack app in Go, but I tried to make it clear for any language. Let me know if anything is unclear or needs expanding on - this is my first time giving back to the Stackoverflow community.
Related
I've built a Rails app, basically a CRUD app for memos/notes.
A notes title must be unique. If a user enters a name already taken a warning message is shown prompting them to chose another.
My question is how to make this latency for this feedback as close to zero as possible. When creating a note little UX speed bumps like this will get annoying for user quickly.
Of course the main bottleneck is the network. Inspired by Meteor (and mini-mongo) I was thinking some kind of local storage could be a solution?
I.E. When app first loads, send ALL JSON to the client with ALL note titles. The app (front end is Angular JS) could check LocalStorage (or App Cache, Web SQL?) instead of incurring a network round trip. The feedback would be instant.
I've used LocalStorage in the past to augment an app, but in the scenario it'd really seriously depend on it. I'm not sure how confident I'd be building on something that user might not have. Also as the number of user Notes/Memos I have doubts how feasible it is to send a JSON object down the wire with ALL the note titles. That might get pretty big. On the other hand MeteorJS seems to do this with no probs.
Has anyone done something similar or have any pointers? Thanks!
I don't know how Meteor works here, but you're right that storing all note titles in localStorage is not a good idea. Actually, you don't need localStorage here, you can just put it in a JS array, because you need this data only once (when checking new note title).
I think, there could be 2 possible solutions:
You can change your business requirements and allow non-unique title. Is there really a necessity for titles to be unique?
You can verify note title when user submits form. In this case you can provide suggestions for users, so they not spend time guessing vacant title.
Or, if titles must be unique only within a user (two users can have same title for their notes), you can really load all note titles in JS array and check uniqueness while users types in a title.
Or you can send an AJAX request checking title uniqueness as soon as user finished typing the title. In this case you can win some seconds.
Or you can send an AJAX request as soon as user typed in 3 symbols. The request will return all titles that begin with these 3 symbols, so you don't need to load all the titles.
I am building an app where I am fetching some data (e.g. persons, documents ...) from a server. I am building the app for iOS and Android. On Android i got it pretty decent looking ;), but on iOS I am not really sure how to properly design it(because I don't want to get it rejected by Apple). All of the apps, which I saw, that are fetching some data from a server just need one paameter and they are good to go. In my case I have a lot of parameters which can be used (for a person there is the name, email, postal address, phone, person type ...) and in the end you get a list (so I need a table view). Now I am not sure how to present that to the user. So far I have built a slide menu on the left (there is a navigation button which opens and closes it) and there I have placed all of the additional search parameters.
The main search criteria would be by name and I thought to use it with the search bar and the search display controller(so you dont have to open the slider for a search over the names). The problem is that I am also using sliding cells (e.g. to call, send sms, send email to persons), and when searching with the search controller I always get a blank table (it seems that the search contoller can't handle custom cells). Then I switched to using the search bar (without the controller), but there is the problem that I am mssing the scope bar und the whole animation thing (I assume that I will have to create all of it manually)
Has anyone built some app like that ? What are the best practices for doing so (I am comming from the android world, so I am not sure what the average iOS user expects) ? For reloading the table I use just the pull-down mechanism ? Is that enough or do i need some additional bar buttons ?
It would be great if someone has a working example (in the appstore would also be fine), or a link to some explanation on this matter.
Kind regards
I'm once again looking into the world of tabbed browsing and Sessions. Looking over a few google searches it seems that there isn't a nice way of supporting this.
Does anyone know of a method that allows Bookmarking without stealing a session (cookieless) (and this doesn't work in MVC2 for dataannotations).
Supporting tabs in such a way that it's per use case (like Windows Workflow), going through two workflows at once.
I'm thinking a url in the query string might support this, but I'm wondering if anybody else has done a similar implementation.
[Edit] Use Case: Say I'm writing an application that uses something like Windows Workflow. Each UI workflow may do an action such as collect settings of a page and execute some external process. I may wish to do two of these workflows at once (not necessarily the same UI workflow). As such if I saved in session I would get:
a) Different tabs interfering with the workflow
b) Previous/Next buttons would be extremely difficult to work out, due to a).
I would like it so either, a user cannot open another tab to a url (don't think there is a 100% method of preventing this), or allow a user to use a UI workflow in isolation without one affecting another (much like running two workflows in two different browsers).
Hopefully that gives an indication of what I'm attempting to do.
Regards,
J
It sounds like you might be trying to do the following:
For example, let's say you have a two page questionaire, the first page has first name on it and the second page has last name on it. You desire that the user can open two tabs, and be at different pages in the questionaire while entering different data in the questionaire in each tab.
So in Tab A, you have entered Mark as the first name and submitted and you are at page two now in Tab A. You decide you are going to do a questionairre for your friend also, so you open up a new Tab, Tab B. In Tab B you enter Tom and submit the page.
Currently in the browser you have Tab A, which is at page 2 of the questionaire with firstname = "Mark" and Tab B which is at page 2 of the questionaire with first name = "Tom". Assuming you wanted to maintain both of these in session on the server here is an approach that i think will work for you.
When a web browser requests page 1 of your form, on a GET request(no posted questionaire data to the server), you supply a hidden field in the the response html and generate a random number to store in that field. When this form is submitted you do the following on the server:
Look in session using the random number as a key "var questionaire = session[Request.Form["questionaire_rnumber"]]
if the questionaire is not in session you create a new questionaire and update it's properties and stick it in session
var questionaire = new Questionaire();
questionaire.FirstName = Request.Form["firstName"]
session[Request.Form["questionaire_rnumber"]] = questionaire;
if the questionaire was in the session you simply update the object, and display the next page, however when you display the next page you will want to supply the hidden random number field in the html again, using the same random number you used on page 1.
This way you can hold any number of questionaires in a single session. With MVC.NET it should be straight forward for you to add the random number field to your view model and add the logic for looking in session for an existing questionaire or creating a new one and I think you'll be good to go.
You should keep in mind the possible issues with the approach also, like back button issues, security issues, and performance issues.
One example of a security and a performance issue would be that an attacker realizes your application works like this and the attacker requests page 1 of your form 10,000 times and submit the page 1 each time. You would have 10,000 questionaire objects in that one user session. If the attacker deleted his session ID cookie 10,000 times and for each session id cookie he created 10,000 requests for page 1 and submitted the page 1 form, you would have 100,000 questionaire objects cumulatively across 10,000 sessions on your server. So you should put some constraints on it also to protect your application, for example:
Any individual session can only have X questionaires in session
Any individual IP address can only have Y concurrent sessions (this you would probably need to track in the Application object)
ADDITIONAL RESPONSE TO ADDED USE CASE
Thanks for the use case. My solution should still work for you. You have two options.
If you want to ensure there is only one tab working with your workflow, then when the random number is passed to the server from a new tab you will be able to detect that there is another workflow in progress and that the random number from the new tab does not match the random number from the first, so you will throw an exception and show the user some messaging that says they can't start a new workflow until they finish the first one, and ask if they want to cancel the first. You have to ask if they want to cancel it because if they close their browser on the first workflow they started they will be stuck until their session expires. Which won't happen if they keep trying to start a new workflow.
Secondly, you could allow them to do multiple, but segment the context of each workflow by the random number, as suggested in the first answer. The whole point is that you are making little mini-sessions in your session, but keyed of a value that is only stored in the client. So since each tab has a different random number when the form posts to the server, it's easy to correlate that random number with an entry in your session that has all the information about the workflow initiated from that tab.
Hope this helps.
You need to store wizard state information in the client in some way, via query string or form values. As you've intuited, Session will not work. Nor will anything else that relies solely on what is on the server.
I want to write an application that assigns Fogbugz cases programmatically, how would I accomplish this? Is it possible to achieve this given any of the following scenarios:
The user enters text in my
application's input field and the
Fogbugz report is opened in the
browser where the "note" field is
populated with the text from the user
input
The fogbugz report is assigned to the
specified user in the application
without the browser even being opened
i.e. the report is stored directly in
the DB.
I'm planning to add default values to the other fields as well so I would assume the process would be the same for adding text to the "note" field.
You can do this with the Fogbugz API. See the heading "Editing Cases" for the specifics on how to edit a case (which includes creating a new one). It's a little complicated (or perhaps just oddly designed) but, as I remember, you basically have to call cmd=new if you want to create a new case, supply your text in the 's' parameter and set the ixPersonAssignedTo to the correct person. For an existing case, use cmd=edit.
This is possible both with a regular form posted to your Fogbugz installation and some server side code that calls the API.
You might want to write a plugin for FB and allow others to use it. (share it or sell it)
I have made a little app for signing up for an event. User input their data and click "sign me in".
Now sometimes people are double in the database, the exact same data that got inserted 2 times very quickly after each other. This can only mean someone clicked the button twice, which caused two posts to happen.
This is common web problem, as credit card apps and forum apps often say: "Clicking once is enough!".
I guess you could solve it by checking for the exact same data to see if the post is unique, but I wonder if there are other methods.
This ofcourse does not count for ASP.NET webforms, because POST doesn't matter as much.
While JavaScript solutions can disable the submit button after it has been clicked, this will have no effect on those people who have JavaScript disabled. You should always make things work correctly without JavaScript before adding it in, otherwise there's no point as users will still be able to bypass the checks by just disabling JavaScript.
If the page where the form appears is dynamically generated, you can add a hidden field which contains some sort of sequence number, a hash, or anything unique. Then you have some server-side validation that will check if a request with that unique value has already come in. When the user submits the form, the unique value is checked against a list of "used" values. If it exists in the list, it's a dupe request and can be discarded. If it doesn't exist, then add it to the list and process as normal. As long as you make sure the value is unique, this guarantees the same form cannot be submitted twice.
Of course, if the page the form is on is not dynamically generated, then you'll need to do it the hard way on the server-side to check that the same information has not already been submitted.
Most of the answers so far have been client-side. On the server-side, you can generate a hidden field with a GUID when you first produce the form, and then record that GUID as a submitted form when the post is received. Check it before doing any more processing.
Whenever a page is requested from the server , generate a unique requestToken , save it in server side,mark status as NOT Processed and pass it along with the current requested page. Now whenever a page submit happens , get the requestToken from the "POST"ed data and check the status and save the data or take alternate action.
Most of the banking applications use this technique to prevent double "POST"ing.So this is a time proven & reliable way of preventing double submissions.
A user-side solution is to disable the submission button via Javascript after the first click.
It has drawbacks, but I see it often used on e-commerce websites.
But, it won't never replace a real server-side validation.
Client side techniques are useful, but you may want to couple it with some server side techniques.
One way to do this is to include a unique token in the form (e.g. a GUID or similar), so that when you come to process the form you can check to see whether the token has already been used, preventing a double submission.
In your case, if you have a table with event visitors, you might include this token as a column.
A client-only solution won't be enough, as stated in many of the answers here. You need to go with a server-side fail-safe.
An often overlooked reason that disabling the submit button doesn't work is, the user can simply refresh the submit target (and click OK on the "are you sure you want to resubmit the POST data?" dialog). Or even, some browsers may implicitly reload the submitted page when you try to save the page to disk (for example, you're trying to save a hard-copy of an order confirmation).
Almost no one has js disabled.
Think about coding your e-commerce website for the 70 year old woman who double clicks every link and button.
All you want to do is add a javascript to prevent her clicking "Order Now" twice.
Yes - check this at the server side too "be defensive" - but don't code for that case. But for the sake of a better UI do it on the client side too.
Here are some scripts that I found:
//
// prevent double-click on submit
//
jQuery('input[type=submit]').click(function(){
if(jQuery.data(this, 'clicked')){
return false;
}
else{
jQuery.data(this, 'clicked', true);
return true;
}
});
and
// Find ALL <form> tags on your page
$('form').submit(function(){
// On submit disable its submit button
$('input[type=submit]', this).attr('disabled', 'disabled');
});
None of the solutions address a load-balance server.
If you have some load balancer, send a UUID (or any type of unique number) to the server to store and read again will not work well if the server is not aware of other servers, because each request could be processed by a different server in a stateless environment. These servers need to read/write to the same place.
If you have multiple servers you will need to have some shared cache (like a Redis) among the servers to read/write the unique value in the same place (what could be an over-engineering solution, but works).
Client side alteration is a common technique:
Disable submit button
Change the screen to a "please wait" screen
If the form was modal, changing the screen back to their usual process (this has the benefit of making things look really slick)
But it's not perfect. It all relies on JS being available and if that's not the case, without back-end duplication detection, you'll get duplicates still.
So my advice is to develop some sort of detection behind the scenes and then improve your form to stop people with JS being able to double-submit.
You can track the number of times the form's been submitted and compare it to the number of unique visits to the page with the form on it in the session.
Beside the many good techniques already mentioned, another simple server-side method, that has the drawback of requiring a session, is to have a session variable that is switched off on the first submit.