I have the following tasks hierarchy: Epic-Story-Task.
I want to create an agile board where swimlanes are epics and cards are tasks. But when I create it tasks appear to uncategorized swimlane. Is there a way to configure board as described?
Related
We are evaluating a chat solution for a system we are developing. Twilio Conversations is our preferred option, as we also plan to use video. Our requirement seems to be a bit atypical of most solutions, and we are trying to determine the best architecture.
The solution is for a healthcare provider. Patients will be able to chat, via a mobile app, to a number of teams in the clinic, who will converse via a web app. Clinic staff can belong to several Teams. Chats can be initiated at both sides.
We are trying to determine the best architecture for Team members. Chat responses should come from the team, not an individualand any team member should be able to continue a conversation.
So, do we have one chat user per team? This seems to make sense, except a Team member could be in several teams, so we would need to handle multiple identities.
Or do we create a group comprising each team member plus the patient? This doesn't seem the rightr approach. We would need to hide the individual user identities, keep responses in sync using horizons, and I doubt would scale well?
I'm surpised this isn't a common scenario, so was wondering if there ws a recommended architecture? Thx
Good evening people,
I would like to create Katalon interface tests on a system under development, but I am having difficulty. The system involves an icon of a car that needs to travel through a stream, but to get it out of some processes (such as arrival, middle, and end), it receives Swagger parameters that simulate or PLC bus, like closing a gate to let the car out, for example.
Can I create an automated test that sends this information from swagger by importing Swagger's JSON in Katalon? Is there any other example besides PetStore?
Thanks
I am trying to develop a RN application which would contain different screens, based on the role of user logged in.
Application would have 4-5 roles and each role would kinda be like a whole application within itself.
I am undecided as to what kind of architecture should I have if I am looking to incorporate all these roles within one application only. Or if I should go about making a separate application for each role?
I think more important than the roles will be the actual tasks your roles have. I'd create a matrix for getting clarity on which role requires which tasks. You then write task specific ui screens/components and show/hide based on the role matrix. This will probably be the most logical architecture and promote reuse of your task oriented ui components. Imagine a new role comes into the picture for your application - Or a new task. For both cases this architecture is easily extensible/changeable.
You can do this approach with writing a single app for all roles or a separate app for each role - Your task specific modules will be reusable in either approach.
And the comment to use redux for state management is a somewhat different topic, but generally not bad advice for a reasonably complex app. Just read this to get more clarity.
Can we use the Existing Actions Cards which are already there in kaizala app or we have to create our own custom card? If so, then please help me to create custom action to fetch data and send data using API to app using Kaizala existing actions?
You can use available out-of-the-box Kaizala Actions. They include:
Announcement - make key announcements or share updates
Job - assign jobs to people and track completion status
Let's Meet - invite people to meetings and confirm their availability status
Live Location - request live location and help people find their way
Photo with Location - share a picture with your current location
Quick Poll - ask a question and get people’s opinion
Request Location - request people to share their location
Share Location - share your location with others
Submit Bill - submit your bills and expenses
Survey - ask a series of questions and get people's opinions
Checklist - create to-do lists and capture everyone’s status
If these Actions do not suffice your requirements, you can also build custom Kaizala Actions for your needs. However, development of custom Actions is under preview mode and we are testing it out with our limited partners/customers. If you want to try out development of custom Actions, please feel free to reach out to kaizalaDev#microsoft.com
We will help you out with your requirements of fetching data through API within custom Actions, once you reach out. However we have publicly available REST APIs to let your systems integrate with Kaizala.
Is it possible to intentionally lock a Rally defect in such a way that users are not able to create tasks for the defect?
Our metrics collection tools are working off Rally stories. Our process for defects is supposed to be, the user creates a task or tasks under the original story which spawned the defect.
Unfortunately, not all the team members remember/follow the process. We end up with tasks associated directly to the defect which don't get reported on in our metric data pulls.
I suppose I could rewrite the metric data pull apps, but as a quick fix I am looking to just prevent the creation of tasks on defects.
Unfortunately the Rally permissions model is not that granular. Tighter control over the permissions model is a popular feature request. I'd encourage you to vote on the following:
More granular user permissions
Idea at Rally Ideas
To garner votes and visibility for this enhancement request.