Apart from "Promote Dynamic parameter to webtest parameter"(which binds session key only),
Can we able to bind fetchgriddata=>grid name,execute grid action,etc? for which extraction rules are user defined.
Immediately after a test is recorded, Visual Studio asks whether it should "Promote dynamic parameters to webtest parameters". If you are not sure then answering "Yes" is normally best. After recording and promoting dynamic parameters the test can be further customized (i.e. made to work). One of the tools is the use of extraction rules and then using the extracted values in later parts of the test.
The way that promoting dynamic parameters to webtest parameters works is by creating extraction rules and inserting the values where needed. This automated detection of dynamic data finds many things but it does not (and I think it can not) find all dynamic data items. Hence the test author often needs to find other dynamic data items.
Back on the details of the question. You cannot add extraction rules to a web test before "Promote dynamic parameters to webtest parameters" is asked. Hence the values in your extraction rules cannot be automatically bound into the test.
See also this page which has some more details.
Related
We want to "Categorize" our work orders more systematically. So far, we've been using Description, but we feel it is not a reliable way. We were hoping to use Failure Class as a starting point, but we find that having on a different tab discourages technicians and the help desk from classifying the work order.
Is it possible to add/duplicate the Failure Class field to Work Order Tracking screen?
Normally, I wouldn't ask, but was not clear if this was possible because Failure Class, Codes, and Tracking are different tables in Maximo. So, I wasn't sure how this would work exactly...
The simple answer is to use Application Designer's copy / paste functionality to duplicate the field. The specific field in question is on the top level of the Work Order Tracking application and facilitates interaction with the FAILURECODE attribute of the Main Object of the application, which is WORKORDER. Therefore, a copy / paste operation should be all you need. (Note: Application Designer's copy / paste functionality is used via that application's toolbar buttons, not Ctrl+C / Ctrl+V.) And if using Application Designer's copy / paste functionality doesn't work to your satisfaction, I would recommend exporting the XML for the application, copying the line of XML as desired and giving it a unique id, and importing the updated XML back in to Maximo. (Application Designer has toolbar buttons for exporting and importing an application's XML.)
You mentioned difficulty getting users to fill it in as a driver for asking the question. Another solution, which you can do as well as or instead of copying the field, is to specify the Failure Class on each Asset. Then, when an Asset is put on a Work Order, its Failure Class will be copied over, saving the users work and risk of not choosing correctly. And another idea is to highlight the Failure tab until a Failure Class is supplied.
And you also mentioned that the driver behind getting them to fill in the Failure Class, and etc, was to help categorize work. To that point, you should know that Failure Classes, in specific, and Failure Codes, in general, are intended to be used to help you determine what's going wrong with your assets, how often, and how the problems are being fixed. So, using them to categorize work is a bad idea. Instead, you should be using the Work Type field and Classifications, because categorizing work is what these are meant to be used for. The Work Type field is already on the Work Order tab, and Classifications fields are on the Specifications tab. You could copy the Classifications fields the same as I directed above for the Failure Class field.
We are using SonarQube 4.5.1 for our projects and are planning to provide list of rules activation/deactivation to end users.
What is best way to export/import within SonarQube in Excel?
There is option of backup in Quality Profile but it did not export description.
I looked directly in the database with rules table, but due to some HTML tag this is not working for delimited with semicolon.
I would also like to know how we can add customized rules to existing set of rules. What is the procedure?
The SonarQube interface is really going to be the best referential for your users. Based on the info in your comment, I'd suggest a simple web form rather than trying to construct a spreadsheet.
It may help to know that you can construct the URL to any rule using the repositoryKey and key returned in the XML profile backup:
http://[server]/coding_rules#rule_key=[repositoryKey]:[key]
E.G. https://sonarcloud.io/api/rules/search?rule_key=csharpsquid%3AS907
The API supports many parameters that are documented here: https://sonarcloud.io/web_api/api/rules/search (click the Parameters header above the horizontal line to open the descriptions).
For example, the languages parameter makes it possible to search for rules that apply to one or more languages (a comma-separated list). To get the list of all C# rules, you can use https://sonarcloud.io/api/rules/search?languages=cs
To export the Rules on JSON format:
For C++ rules you can use the URL:
http://<localhost:<port/>>api/rules/search?languages=c%2B%2B
For C rules you can use the URL:
http://<localhost:<port/>>api/rules/search?languages=cs
After saving result of search API in json file, to cover entirely the question, import of json result in excel can be done with https://github.com/VBA-tools/VBA-JSON
Is it possible to use more complicated layer url rule matching syntax? I want to be able to choose the layer to display based on a more regex type rule that matches the rules I have set up in my custom routing for my module.
I would like to be able to acheive something along the lines of:
url('~/my-{\w*}/something/{\w*}')
It's not available ootb, but could be pretty easy to implement yourself in a custom module (if you don't want to alter the core code).
It can be implemented as a slight modification to existing Orchard.Widgets.RuleEngine.UrlRuleProvider, so regexes would be also taken into account.
Just create an implementation of IRuleProvider, name your function as eg. 'urlregex' (so it wouldn't collide with the existing 'url', processed by UrlRuleProvider) and do all the processing stuff inside Process(RuleContext ruleContext) method. It's a very simple class to implement and would involve just a few lines of code - take a look at the default url rule provider I mentioned at the beginning.
Recently, we came across a severe problem in production farm with the Content Types. I would like to explain the background of this problem first.
We have nice working feature for Content Types installation in production and test farms. We developed and deployed (using wsps) this SharePoint feature in Visual studio. We are using the publishing pages using page layouts and Content Types to help content editors to quickly publish the web pages. Unfortunately, some Content Types and site columns have been manually updated/added by some people in the production, so whenever I (developer) make some changes to the existing Content Types (using Visual Studio and feature activation/deactivation) , SharePoint removes one or two columns (during feature activation/deactivation) from Content Types; or the columns which have not been added in a best practice way. I think the best practice is to update Content Types using Visual Studio.
Now, I wish to ensure that site columns shouldn't get removed from Content Types upon feature activation/deactivation.
Note: Our feature for Content Type activation/deactivation doesn't hold any activation dependencies in the feature.xml
Recommended Approach
Based on all these factors, my suggestion would be to:
• Create two Features: one for the original markup and one for making changes. (Or you can put them in the same Feature; I just want to differentiate between where you do what.)
• The original Feature should contain the CAML for Site Columns and Content Types. This ensures the IDs have been assigned ahead of type and remain constant.
• If you want to update a Site Column by changing nearly anything about it except its Field type, do it using a Feature Receiver. By doing this, you can call the Update method and pass in a boolean indicating if you want all the existing assets in the site that inherit from this to update to, (something you couldn't do via the CAML.)
• You can also add an existing Site Column (that you provisioned via the CAML feature) to an existing Content Type (that was provisioned via the CAML feature). This is helpful if the Column was not part of that Content Type before, etc.
• In a scenario like the one I just mentioned in the last bullet point, it's necessary to deactivate and reactive the CAML feature (to provision the new assets) before calling your Feature Receiver. What will this mean for the site? Since all the Site Columns and Content Types in the lists in the site are using the same ID's as the ones provisioned in the Site Collection root, removing its parent from the Site Collection won't change that. It might leave it orphaned temporarily, (i.e. there will be no relationship between that item and an item in the Site Collection root, but it will function the same way it always has, since it's really a fully-functioning copy of the original item) until you reactivate the Feature that puts the item back in the Site Collection. It's like the parents are going on vacation when you deactivate the Feature, and are coming back home when you activate the Feature again.
You have a choice when it comes to how you maintain the CAML and the Feature Receiver, since you have two scenarios: existing Site Collections and new ones.
• You could make a policy that every time you write code in your Feature Receiver to update a Site Column or Content Type, you have to make the change in your CAML as well. That would mean that every time you activated the CAML Feature in a "fresh" Site Collection, the CAML would be up-to-date and accurate; there would be no need to run the "updater" feature. (In your Feature Receiver, you should make sure you do some extra checking to make sure a Site Column doesn't already belong to a Content Type before adding it, etc. in case that change is already in place before the code executes.) This approach means you only have to execute one Feature when creating a new Site Collection, but it also means you're maintaining changes in two places: in your Feature Receiver for making changes to existing sites, and in your CAML for new sites. It's a cleaner approach, but also contains an element of redundancy, which always leaves room for human error.
• The other approach is to simply assume that every time the base CAML feature is activated, you're always going to execute the Feature Receiver. This approach says the only time you'd change the CAML is to add a new Site Column or new Content Type; otherwise, all the changes happen in the Feature Receiver. This approach reduces redundancy, but also means your Feature Receiver code could get quite large with all your changes over time, and it could leave your CAML as very much "legacy" over time.
Src: http://blog.beckybertram.com/Lists/Posts/Post.aspx?List=eb3e1762%2Dbab0%2D4e96%2D8bc5%2Dd67d6e6bfd44&ID=18
Updating Content Types is still one of the underdeveloped portions of Sharepoint which sometimes causes trouble, especially in Content Deployment scenarios.
The best thing in your case would be to always avoid making any changes to content types by hand (using UI)
Whenever you are installing the content type, make sure that you remove the previous one and then install the new one. (Sometimes its not possible due to pages being already created out of it).
My current approach to deploying content types is to do as much as possible using code rather than CAML. That way it is easy to fully control the logic of updates, including ensuring that changes made manually don't cause conflicts. I have the structure defined as attributes on an interface I also use for strongly typed list access, but there are several other ways you could do it.
The only piece that isn't available in the API is setting a specific content type ID, so you need to have a caml file for that, but it's a small/simple file, doesn't try to make updates and is only referenced from a feature that will also run the update code.
I'm doing some work on an existing SharePoint site and part of what I need to do is create a new field on an existing content type.
I'm going to be deploying changes via a feature so I'm debating whether I use CAML to generate the field and then programmatically add it to the existing content type, or whether I can just do it all via the feature receiver.
What would be the best/ cleanest (and most reusable) solution for doing this?
A simple way is to do it in the feature receiver, get a reference to the SPContentType, add the field as XML (SPContentType.Fields.AddFieldAsXml) and then update pushing the changes to child content types
It is really tricky to modify content types on a site that already exists. My preferred method involves having a solution for all the content types and re-deploying that solution when changes are made.
I am going to go on the assumption that by field you mean a new Site Column. In this case I would do it all in the code behind. The amount of code that you need to write to create a site column is rather minimal. You can also attempt to remove the Site Column from any Content Types that are using it if you wish, but this is a task that is quite more involved.
From a reuse perspective if you set-up properties in the feature.xml file you can use those to configure things such as the column name, column type, target content type, etc. and then have a class that can be re-used in the future.
Have you looked at http://msdn.microsoft.com/en-us/library/ee537575.aspx, in particular the < AddContentTypeField> tag? That would be a declarative way to do this.