I use JIRA in Agile mode (with GreenHopper plugin). The only type of issue that can be created is a User Story, and since the "Create Sub-Task" option is enabled, I can create Tasks from a User Story that will be their parent.
I'd like to follow bugs, that will be User Stories with type FeedBack (as, contrary to "standard" projects, I cannot create ER/PR records, User Story being the only one allowed):
User Stories with at least a Task Ongoing should be Started
User Stories with all Tasks Done should be Done too, etc
I tried to define filters via JQL but it does not seem to have such a power (project = LOL AND issuetype = "User Story" AND "Story Type" = FeedBack AND... I miss the possibility to check for Sub-tasks status).
The JQL Tricks Plugin seems to offer such a functionnality (hasSubtaskStatus()), but its license has a cost...
Do you see/know any way ?
Thanks for your help !
Have a look at the script runner plugin
https://plugins.atlassian.com/plugin/details/6820
You can find a couple of examples how-to
https://studio.plugins.atlassian.com/wiki/display/GRV/Post+Functions
You can easily auto transition issues based on a set of business
rules. ie. when we implemented similar scripts, we had to take
into account that a task is paused, such that the parent is affected
also.
Francis
Related
In Maximo, Workorder application, I created one record with material line type in plans tab.
after I approved the workorder, from more actions I selected view->PO information, it is not showing/else its not generating the PR.
Please assist if you know.
Either the Direct Issue flag is set for your work material and the Reorder cron task has not been configured to run or has not run yet, or the material is from a storeroom that has enough stock to cover your material requirement without causing a reorder.
SuiteScript v1, but I'll switch to SS v2 if it's the only way to make it work.
I've tried:
salesOrder.setFieldText('shipcarrier', 'More');
salesOrder.setFieldValue('shipcarrier', 'noups');
salesOrder.setFieldValue('shipcarrier', 'nonups');
But UPS is always selected once the record is saved.
shipcarrier is a bit of an odd thing.
I'm not sure it is actually sticky - in some contexts it appears to be and in some it doesn't.
It appears to be pointless to set unless you are also setting shipmethod.
salesOrder.setFieldValue('shipcarrier', ffShipCarrier); //'ups' || 'nonups'
salesOrder.setFieldValue('shipmethod', ffShipMethod)
PS from cja: My conclusion/solution: Setting shipmode does nothing unless recordmode is dynamic and shipmethod is set at the same time. If both those conditions are met then the value shipmode will be updated.
NetSuite support have warned me against using this solution:
"With regards to your concern, I am able to set the Ship carrier field on the Sales Order record in the client script(nlapiSetFieldValue('shipcarrier', 'ups');) however I was unable to set the value of the field in the server side script. Upon further investigation, the field (ship carrier) isn't exposed in the Record browser hence the field isn't officially exposed for scripting needs. Please refer to the following Suiteanswer article for your reference.
"I am really glad that the solution worked for you perfectly. In order to explain further, I would say it is not advisable to write scripts using unexposed fields in the record browser. It may change in the future without any prior notification and can cause problem and NetSuite will not hold any kind of responsibility for the same.
"User groups contains simple solution to complex tips and tricks provided by the experienced customers. On the other hand, NetSuite Support are stickly adhering to the official documentation/processes to assist any of its customer. The solutions provided in the User groups are totally upto the consent of the customers and can be implemented at their own risk if not confirmed in the official documentation or NetSuite Support."
You need to use setFieldValue and pass the internal id of the "More" ship carrier.
nlapiSubmitField('salesorder', recordid, 'shipcarrier', 'nonups');
I have recently inherited a very messy Dynamics CRM system from my predecessor. I want to clean up the way our company navigates around Accounts. At the moment, there are 3 views and one form with about 2000 (exaggeration) lines of javascript code!
We categorize accounts into three types; TypeA, TypeB, TypeC. This is controlled by an Option Drop Down. Once selected, the screen hides/shows depending on it. This has meant we have a very wide AccountExtensionBase table. I am accepting I will have to live with this as I am have been led to believe that building a 1..1 extension is not as easy as it seems?
What I would like to do is change the 'Workplace -> Customer' menu on the right hand side of CRM. I'd like to add three clickable options so it would read
Customers
Accounts
TypeA
TypeB
TypeC
Contacts
Upon clicking, for example, 'TypeA' it would take the user to the 'TypeA' accounts which are filtered by a pre-defined view. Then, any request for the Account Form from this view would redirect the user to a specific 'TypeA' form, which I have yet to create.
I have read this article here Crm 2011 - How to set a default form depending on attribute value (without using Javascript)? which is a good example of how to re-direct the forms. However, I am unsure how to handle this from a 'New' request, as the drop down is not yet populated.
Is there a way of building this concept cleanly in CRM? I am finding it hard to get any decent Google results as I am unsure of what terminology I should be using.
Any help or links to suitable guides would be hugely appreciated.
Thanks.
I think these are the droids you are looking for:
http://www.powerobjects.com/blog/2013/03/08/displaying-filtered-view-in-site-map-crm-2011/
Granted it is for CRM 4, however it may work in 2011.
You might also look at:
http://mscrmtools.blogspot.com/2011/06/new-tool-sitemap-editor-for-microsoft.html
We need a solution for one of our deployment in bugzilla.
Example of our scenario are as below :
Group : Staff,Students
project/product bugs : projectA , projectB
We need to know is there any way to :
1) Restrict the group of user from accessing the project.
Example= Students cannot access or view bugs in projectA.
2) Restrict other group of user from confirming or change the bug status
Example= Students cannot change the bug status of projectB from NEW to RESOLVED
3) Some members set of group can only file a bug but not close the file
Example= StaffA can only file a bug in ProjectA but cannot closed it whereas StaffB can file the bug and also can close the bug
From what I have search/Google, there are no documentation available which can explain this function in bugzilla.But maybe I have overlooked somehow.
Our current bugzilla is version 3.2rc1
Thanks in advance.
You didn't really say which version of Bugzilla you are using, so the URLs are for the latest release, 4.2. However, the same concepts apply to most recent versions. For instance, we use 3.6 and control whether certain users can change certain things in the same ways that I describe below.
1) Restricting users who are not in a group from seeing bugs is what Bugzilla's group security does:
http://www.bugzilla.org/docs/4.2/en/html/groups.html
One wrinkle in your case is that group security controls positive access rather than negative access. That is, it allows specifying which groups can view bugs in a product rather than groups that cannot. To keep members of students from viewing bugs in projectA, you'll need to have a group that can access projectA and devise a way to keep users in students out of that group.
Alternatively, you could put some custom code into Bugzilla::User::can_see_bug, Bugzilla::User::visible_bugs, or Bugzilla::Bug::check_is_visible to exert firmer control that users who are in group students can never see bugs in projectA
2) You can exercise a lot of granularity in allowing changes:
http://www.bugzilla.org/docs/4.2/en/html/cust-change-permissions.html
We do something like this. We have a set of users to whom we want to grant read-only access unless we have explicitly allowed read-write access. To do this, we have a group called allspecialusers to which these users belong based on email address. We have another group called approved_specialusers to which some of those users are added manually.
So, in our Bugzilla::Bug::check_can_change_field, we have code like:
if ($user->in_group('specialusers') &&
!$user->in_group('approved_specialusers')) {
$$PrivilegesRequired = 3;
return 0;
}
You can do what you want by checking if the bug is in product projectB and the user trying to make the change is in group students
I've just started to look workflows in 2010 which seem pretty good but I can't find seem to find out how do something very simple.
Basically I'm creating a lost property list and workflow, essentially anyone can add a new item to the list for an item that they've found. Next anyone can make a claim on an item in the list which should then email the admins where they can investigate and close claim if the rightful owner has claimed their item.
Should be very simple and would take me no time in .net but not in SharePoint! Any suggestions on how I could do this?
I've been looking at SPD workflow tasks and not really getting anywhere. My next step is to go into VS2010 but this seems overkill for such an easy task.
Thanks
Dan
what is your intention to allow someone to "claim?" are you intending to enable a "claim" as just a flag and a workflow sending emails to the admins?
Create a Yes/No field Claimed with the default value set to false.
Create a SPD Workflow that would start OnItem Create.
In this workflow add an Action that waits till the Claimed Flag is set to true.
Then you can send the email to the administrator (also with an SPD activity).
Optionally you can delete this item from the list after a period of time.
Based on my understanding of your question and the fact that we tried something similar a while back, I have created a blog (my first blog entry!). Below is the link, feel free to leave comments;
http://sp10tech.blogspot.com/2010/10/creating-simple-workflow-using.html
Alternate Idea;
Maybe use two lists. One for items lost and one for claims. This way you can have multiple claims on each lost item. Add a field that references the claims list so the user can select it. Then simply have the administrators use a out of the box alert mechanism. No need for elaborate work flow.