As a Product Owner, I would like to have three start tabs in my browser. Previous, current and next sprint. Of course without having to change them with each passing sprint.
URL for current sprint for me is:
https://dev.azure.com/[company]/[Project]/_sprints/backlog/[Team]/
(inspired by this post, but slightly modified)
I seek to have same time-independent link to previous and next sprint. Is there a URL like above for this, can I make a query that I can call using a URL or another solution?
Related
For a given survey, how do you determine its survey_id for use with the SurveyMonkey API?
A list of all IDs is returned by the API method get_survey_list, and you could subsequently call get_survey_details on each survey to determine which one is the intended one, but that seems needlessly complicated. There has to be a way to get a survey's ID from the My Surveys page, right?
Edit:
Whoops, get_survey_details isn't actually necessary, since get_survey_list can take a fields parameter that includes the survey's title.
If you want to get the survey ID via the web page you can:
Right click on the survey in the "ALL SURVEYS" surveys view, and press "Inspect Element" or "Inspect" depending on your browser.
In the bottom of the browser, you will see a highlighted block that starts with:
<a href="/summary/...
Scroll up a few lines until you see a line that starts with:
<tr class="survey-row" id=`
The number that follows id= is the survey id, which you can then use in the API.
Nothing much to add to what Tony & Miles said, just that my UI form contains these fields:
1) An Age limit - eg the past 365 days
2) A keyword in the title - typically all the surveys for one client have that client's name in the title. Hint: if you can be organised enough to enforce a convention, and put keywords in the nickname, the nickname is what the API looks in for Title, although what the user sees is the other title.
3) A start date to get responses only after a start date - the first day may have been only a test.
4) A combobox with all the matching surveys is presented showing the title, number of respondents, date created and date recently modified, pretty much the same as what appears in the SurveyMonkey web UI. That's where they pick the one they want.
HTH
Patrick
Say I have a list of orders I want to display. I want to give the user the ability to show all orders, all orders from a certain state, and all orders from a certain category. Each of these can be filtered by a date range.
Without worrying about routing, I might just add each on the query string:
/orders?State=TX&Category=Books&DateRange=Yesterday
While I could easily make this work, it doesn't "feel" like this is the correct MVC-way of doing things.
I could have routes that look something like this:
/orders/
/orders/state/{state}
/orders/category/{category}
/orders/state/{state}/category/{category}/
/orders/state/{state}/category/{category}/Date/{date-range}
But I'd still want to support each of those filters not being there. Is there a better way of handling this or am I just over thinking the whole thing?
If I go the URL only path, it isn't clear how I would create these routes without just repeating them for all the combinations I would want (state, no category, date, state, no category, no date, no state, category, date, etc.)
I think the query parameter version is fine for MVC. What's probably confusing you is that, when you want to give the user a page for a specific order, you do put the order_id in the page. So where in a traditional website, you'd just make that URL
/order.html?order_id=1234
(or whatever), with MVC you want to use
/orders/1234
instead. The difference is, you only want to put mandatory parameters --- those that the page would break without --- in the URL; not every parameter. You can't return an order page without an order id, so that goes in the URL.
You can have both on a page; for a silly example, if you had a shipping tracking page for an order, you could have a URL like
/orders/1234/tracking?since=9%3a00
to only show tracking events (arrived at, departed at) since 9:00am.
It's actually a common practice to leave search/filter options in query parameters, look on google for instance.
From my point of view, unless you care about seo on filter results or want to have human friendly urls for this page, the is no point in supporting routes for any possible filter.
in our Company we have a Sharepoint 2007 Server which we are using to keep track of our cars.
What I try to achieve is to have a aspx page where you can select a car of the cars list and then click "request". If you did that the page must switch to another text saying something like "car request in progress" (and of course hide this car in the cars list if the next person enters this page) and send an email to someone which contains two buttons: "accept" "decline". If he clicks "decline" the cars status has to be set to available again so someone else can do a request for this car again. if he clicks "accept" another person gets an email telling him that person1 requested this car and this has been approved by person2. this emails are easy to create using workflows which are waiting for the status to change but how can i create a link which changes a cars statusfield in the cars list and what code do i need in the aspx request page?
Thanks in advance!
MemphiZ
Make a link that, when clicked, will run the appropriate action on the users behalf. If you are using workflows, this is as "simple" as changing the items property and letting the item-change event be handled. Make sure to avoid cyclic changes.
This can be done trivially by encoding the items GUID (and perhaps list and action and whatever else you want) in the URL; the GUID can be used with the SharePoint Object Model for the lookup.
Perhaps the above can be done using SPD without a separate/"code" ASPX, but I don't touch that pile of "fun".
Edit for comment:
In my scenario we just encoded the link as http://foo.com/whatever.aspx?id={THEGUID}. The aspx handler just read the query parameters. Item editing ability used standard SharePoint list permissions. Double-submissions were rejected because after the link is handled the item modified to be in a new state which does not accept said link-action (thus clicking the link again simply resulted in no-operations). Working out a total state-diagram before starting work can save lots of time.
I have a search page which finds candidates.
From this page you can click view to find more information about the candidate.
When on the candidate view you can click edit or do a number of other actions which would return you too the candidates view.
My problem is from the candidates view I need to add a button to go back to the search results.
I originally thought of using a JS button with history -1 but because the user can do other action from inside the view this won't work.
I am still quite new to rails so not sure of my options... I am thinking some sort of caching of the results and then maybe a hidden field to keep track of the location of the cache(don't think this is the best solution as keeping track of the hidden value could get abit messy!)
Thanks, Alex
I would probably use a session variable to store this information.
First, make sure your form that posts to the search page is a GET operation, this way the search details are in your query string. Then in your search action, you can grab the request URL and store it in the session:
session[:search_results] = request.url
Now in your view for the results, you can do your "Back to search results" like this:
link_to "Back to search results", session[:search_results]
You have a couple of options:
Cache the results, as you've suggested. The potential downsides to this are that it takes memory, and if new valid records get added, you won't see them. You could store the cache in Session, or in the database (though in the latter case, you don't gain much).
I'd suggest just remembering the last search term, either in session or using hidden fields. You end up re-running the query when you go to the search results page, but in a properly indexed DB, that shouldn't be a big deal.
Good luck!
You can include the parameters for the query on the subpage. Eg.: /foo/search?q=stuff displays search result. Each result then has a link like /foo/:id?q=stuff. And on the subpage, you will have the parameter available to link back to the main page.
This solution doesn't use any server side state, which is generally accepted as the better way to build web applications. Not only does it mean that you browser will behave as expected, with respect to bookmarks, multiple tabs etc., but it also ensures that proper caching can be employed. Further, it lowers the complexity of your application, making it easier to debug and extend.
You could put the search results in a "search_results" table keyed by the user id. Then when the user hits the page, always load from a query on that table.
If anybody does come across this page and you need a button that goes back to the previous page and still display those search results (just like the google chrome button), just use :back.....
<%= link_to(image_tag("back.svg"), :back, :class => 'back_btn') %>
I have a detail page that gets called from various places and has a nice readable url like
"www.mypage.com/product/best-product-ever".
The calling pages (list of products) have a more complex url like:
"www.mypage.com/offers/category/electronic/page/1/filter/manufacturer/sony/sort/price" and
"www.mypage.com/bestseller/this-week".
How can I make a backlink from the detailpage to the calling product list?
I cannot use javascript
I don't want to have the calling page in the URL, because it gets to long
I really want links between pages, no http-post
I cannot use Sessionstate
EDIT:
Sessionstate is ruled out, because if there are 2 Windows open, then they would share the same "Back" page information.
Like Lee said, use the referrer value:
Back
If you don't want the URL in the link because it's too long, try running some sort of simple compression algorithm over the URL, display the compressed data as unicode text and then append the compressed URL as a parameter to a redirect page, e.g:
Back
What about using the referrer header value?
Here's a crazy idea that will require a fair but of work and may not be healthy for performance (depending on your users).. but here we go:
Create a repository for caching 'ListResults' (and wire it to persist to the DB of you like.. or just leave it in memory on the server).
In short what this Repo can do is store a ListResult which will include everything to persist the state of the current view of the list any given user is looking at. This might include routes and other values.. but essentially everything that is needed to redirect back to that specific page of the filtered and sorted list.
As the ListResult item is added to the repo a small unique hash/key is generated that will be url friendly - something like this "k29shjk4" - it is added to the item along with a datetime stamp.
ListResults are only persisted from the moment a list gets off the default view (ie. no filtering, sorting and Page 1) - this will help in a small way for performance.
A ListResult item may never actually get used but all detail actionlinks on the particular list view have the ListResult.Key hash value added to the route. So yes, it might end up as a querystring but it will be short (url friendly) and if you wanna mess with routes more, you can tidy it up further.
For navigation "back" to the list, you may need a new small controller which accepts simply the ListResult.Key hash value and redirects/re-creates the state of the list view (paging, filtering and sorting included) from the lookup in the repo.
So we have met the requirements so far: no calling page in the url (in the sense that its not the whole page - just a hash lookup of it); no POSTing, no sessions, no js.
To stop the ListResult repo from getting to big (and dangerous: if you persist it to the DB), you can use a ASP.NET background service to periodically prune the 'old' routes by way of the timestamp.. and 'extend' the life of routes that are continuously being used by adding time to the stamp of a ListResult item when it's requested via the new controller. No need to persist a route indefinitely coz if a user wants a permalink to a list view, they can bookmark the long list route itself.
hope this helps somehow
Do you have a cookie?
If so, you can put it in there, or use it to create your own session state.
I think this is more like a "Back to results" then a generic "<< back" link, because you would expect the generic back link to return to the genetic list, not the heavily filtered list you described, right?
I don't know if this falls into your "no post" condition, but the only option I can see is having the Detail action be POST-only ([AcceptVerbs(HttpVerbs.Post)]) and include another parameter like string fullRoute which is converted to the 'link' on the detail page for "Back to results". Overload the Detail action missing the fullRoute param and have the overloaded action be a GET action so that the POST fullRoute value is not required (for when users are ok with the 'generic' "Back" link). This should serve both 'generic' GET requests to the Detail page and the POST request which will include the specific "Back to results" link for the filtered list.