When we launch/initiate a process from process portal in IBM BPM, first human task of the process appears in the work (task inbox). But that user has to claim it explicitly to work on the task and that is a problem in my case.
What I want to achieve is: who ever launches the process from portal should land immediately to first human task so the user doesn't have to claim it explicitly
Unfortunately, this feature is unintuitive and poorly documented. Fortunately, it is very easy to do. It's one of those things that everyone "just knows" and is, by far, everyone's first question when using the product. Here's the trick:
If you set the user distribution for the first human activity in a BPD as "last user" ("last user in lane" for older versions of the product), it has a special meaning to the system that indicates that the task should be immediately assigned the user that started the process and the first coach be immediately displayed (assuming the user has the permissions to that activity, and the BPD is able to immediately flow to that activity).
In theory, this is documented here: http://pic.dhe.ibm.com/infocenter/dmndhelp/v8r5m0/index.jsp?topic=%2Fcom.ibm.wbpm.main.doc%2Fic-homepage-bpm.html under "last user", but the docs are very confusing. Even to me, and I know what it is supposed to be saying.
If you want to make the user to flow human tasks without return to his/her inbox in
process portal
so you should do from process designer two things
first put the assignment to be last user in the lane
and the second make true on check box on every task in the land you
want to follow automatically to next task.
Related
How can I (force) stop receiving the Sumo Logic alerts?
I have scheduled a Sumo Logic search, and started receiving the email alerts. However, after I unscheduled it (Run frequency = "Never") and even deleted it, I'm still receiving these alerts. It's been over 24 hours now.
I am looking at our org's "Library"; that's where I deleted the scheduled search. Is there anywhere else I can look to see why it's still running?
You may have multiple copies of the same query.
When you receive Alert email, it includes a link to query. Open the link and then “Edit” it, then change schedule to “Never”
With the help of Sumologic Support, I got to the bottom of this.
In short, I had saved my scheduled search elsewhere (duplicating it) by mistake, and it was this other instance (of which I was unaware) that was sending the alerts.
Looking back, this is where it had gone wrong:
first, I created a scheduled search by running a Sumo search and clicking "Save As"; I saved it to a team folder, where it really belonged
some time later, I must have run the query again and clicked "Save As" again
this is wrong; after a query is saved once, it should be modified via the "Edit" link, not "Save As"
what's worse, the "Save As" dialog offers my personal folder as the default save location, and I must have overlooked it, thus producing a copy of my scheduled search
at this point, I had two identical searches scheduled: one in the team folder, and one in my personal folder (which I didn't know about); no matter how I modified the scheduled search in the team folder, even deleting it, I never stopped being alerted (because the other search was still active)
I recommend using Sumologic Support; they accessed my account, looked around, and quickly figured out what was wrong.
I just started using Asana to manage bug fixes/feature requests from my clients, and I can't hardly believe that every single time I open it I need to manually ask it to show me unassigned tasks and assign them by hand to myself to get them to appear on the My Tasks view. Anything coming in by email (which is how I'm going to have my clients do it) is unassigned, and Asana gives me absolutely no clue when I log in if an unassigned task is waiting for me to assign it, and it will remain hidden from my to-do list (the My Tasks view) until I do.
There are existing solutions on SO for how to search to find unassigned tasks; those are not what I'm after, as those are how to do manual one-time searches, but I want Asana to tell me the things I need to know about without me either having to remember to manually ask for them every single time I log in, or risking missing something time-sensitive.
Alternatively, if it would either automagically assign mailed-in tasks to me, or let me set my "All Tasks" bookmark to be the default view as soon as I log in, either of these would suffice. I can't find any way of doing any of these things—my goal is that 100% of user-submitted tasks be brought to my attention without me having to remember to look for them (otherwise I could just stick with my dubious previous system of remembering to search my email inboxes.)
If you're using one email address to assign tasks (from a form or whatever) you can go to account settings -> from email and add your email address. That will automatically assign those tasks to you.
Here's the asana docs for it: https://asana.com/guide/help/email/email-to-asana
Otherwise, you can use Zapier (or similar service) to manage creating tasks via email for you if you'd prefer not mess around with the API.
Reading online material (e.g. Fowler, Gerard), it seems that Specification By Example stories should not be complete specifications of functionality.
Question 1: How does one starting off with SBE's decide how comprehensive their stories need to be in terms of describing all of the functionality of a system? I.e. when can I stop writing stories because I have captured enough?
Question 2: In an organisation where test teams verify products against the product documentation, if the stores are not a complete specification, am I correct in thinking that 'other' product documentation needs to contain all the cases that are not covered by the SBE's?
Regarding question 1:
The most important part of developing any system is that the development team has a conversation with the product owner. First find out the crux of the feature which they require. I'll answer this question by working through an example; let us say that the product owner may want a facility to login to their new website. This requirement could be written as:
In order to gain access to the website's facilities
As a user
I want to be able to login to the website
(Note that I'm using the Gherkin domain specific language for writing the scenarios and features in this answer)
With the product owner's key requirement specified, you should now discuss with them how you think this feature should be implemeneted from a users perspective (keep it high-level, don't use technical jargon, discuss with the business to find out what they want). So the first "happy path" scenario you might identify could be:
Given a user is on the login screen
When they submit valid login credentials
Then they gain access to the main website
After further discussion with the product owner they tell you that as the website contains extremely sensitive information, and that any failed log-in attempts should be reported to a system administrator. This would result in another scenario:
Given a user is on the login screen
When they submit invalid login credentials
Then the system administrator is informed of the failed log-in attempt
And the user is informed that their login attempt failed
At this point the product owner might say that these are the only scenarios they want for logging into the system. So from the development teams perspective no more investigation would need to be done regarding this feature (so you wouldn't need to write any more user stories). Sure, at a later point in the projects development, the product owner might also tell you that they'd like to inform a user when they last logged into their site before reaching the main website, but you'd only need to worry about this when they ask for it.
Regarding question 2:
The organisation should be verifying the products against "living" documentation e.g. using Cucumber(for example) which generates tests from the scenarios detailed above.
Also as I said in the answer to question 1, you should identify "just enough" of the scenarios/use cases to satisfy the product owner. What the product owner asks for is the complete specification. Don't try and second guess what the product owner might want because this may result in be a classic case of YAGNI.
Having googled, the general advice is to create a standard, non-administrator account.
I just tried that. I only had one account, my own, which is an administrator and then created a second (not the Guest account). I logged out of my own account and into the new one and tried to change the time. Windows 7 popped up a box asking if my main account would allow this (and prompting for its password).
I have been told "it shall not be possible to change system date/time". I intended to deliver a PC with only a standard account and my s/w, but can't (I think) prevent the user from creating an administrative account and changing date/time.
Can I prevent this programatially from Delphi, or do I just have to say that if the user wants to be destructive I can't prevent it?
Generally this kind of restrictions are set using the Windows Group Policy
From delphi you can use the Group Policy API or the RSoP WMI Classes.
In your application, you can actually detect user changing system time while your application is running.
You will receive WM_TIMECHANGE when system time change.
When startup, you can saved the gettickcount (As StartTickCount) and now (As StartTime). When checking, you can check if the different between tickcount and the different between time match (allow a small discrepancy) and know the different. However, if the user change system time away from your application, this trick do not work. Maybe you can have a service which is auto start checking for this.
If you need to change back to original time, here is some resources :
CHANGE the system TIME
btw, in OS level, a normal user cannot create an admin user.
We are looking at setting up an internal web application (ASP.NET MVC) as a kiosk for the employees that don't have a dedicated computer. We currently do not have this kiosk setup. Each employee will have their own login to look at some basic payroll information and request leaves of absence. This same web application will be used by the office workers with a dedicated PC at their desk.
I am going to go out on a limb and say that no matter how many times we tell the employees, the employees will not click log off when they walk away from the kiosk. What would you do to help prevent this from happening?
lets try to fix the users instead of the code :) , i guess that your log out button is like the one here on stackoverflow. its a little text link "logout" some where in the upper right corner. thats perfect for people who use webapps day by day and are aware of the fact that they need to logout before someone comes along a does havoc to thier facebook profile, but less tech savy users wont think of that and walk away.
you need to the get the attention of your users to this logout-button and teach them that logging-out is a good thing.
try the following
give the logout button more visual weight then usally make it bigger, make it a real button instead of a textlink and even change its color to something more alerting (red, orange, ... whatever fits your ci)
if they dont loggout, use the session timeout and some javascript the refresh the page after any amount of inactivity, but also set a flag that this user has not logged out after his last visit. that way you can greet him on his next login with a nice confirmation dialog, and tell him once again why logging out is so important and where your logout-button is located.
The naive solution would be to enforce a timeout. If there's no activity from the user within a certain time limit (say, a minute or so), log them out. Of course, this won't prevent someone from walking up immediately after an employee is done and seeing how much money they make.
ATMs handle this, I think, by timing out after a minute or two, which isn't super-secure but at least offers some minimal security.
If the employees have any kind of RFID card or other security token, you could require them to put it in a reader slot, and log them out whenever the card disappears. Handling this within a web app, though, could get complicated.
The simple way is to use a little javascript.
Just have it set to something like 30 seconds of inactivity. If the user hasn't clicked on anything have the javascript send it back to a login page.
Here's a link to get you started.
Assuming you've already thought of the obvious (aggressive session timeouts, non-persistent authentication cookies, etc); how about a bit of an "out there" suggestion?
I'm not sure how do-able this would be with a web-based interface; but what about using some form of IR sensor with a usb/serial interface and an API you can tie into? This may make it possible to invoke some form of "logout" operation when someone walks away from the kiosk.
Perhaps someone has a better suggestion for external hardware, but this was the first thing that lept to my mind as a out-of-the-box approach.
I found a jQuery version that seems to work quite well. I'll start by using that and see how that goes.