I use filters a lot in Fiddler, to switch between filtering for multiple related sites. However, I'm having problems saving some of these filters.
As an example, if I go to the Filters tab, I can add a single domain like this:
*.example.com
and save it (using the Actions->Save Filterset... button) as example.ffx. In that file, there is a line as follows:
<slHosts>*.example.com;</slHosts>
I then change the filter to also try to include another set of domains which includes a trailing wildcard (e.g. example.co.uk, example.co.au):
*.example.com;*.example.co.*
This filters correctly at run-time, but when I try to save the new filterset (Actions->Save Filterset...), it won't save - it gives me the option to overwrite the existing example.ffx, but it doesn't save - the filters tab reverts to the original value with only *.example.com. This also happens if I save the new filterset under a different name.
This only seems to happen with trailing asterisks - the filters work, but they can't be saved. Even if I manually edit the .ffx file to include both domains like this:
<slHosts>*.example.com; *.example.co.*;</slHosts>
when I load the filterset file, it only includes the first domain in the Filters tab.
Fiddler's HostList object (used in the Filters tab and elsewhere) supports leading wildcards only; it does not support wildcards elsewhere in the string.
The Filters tab's UI should properly reflect the state (e.g. when you move away, it should delete the tail-wildcard rule); I'll pass this bug along to the development team.
Related
I am attempting to remove all references of a managed package that is going to be uninstalled that spans throughout code base in VS Code
I have using a query to find the field permissions but am wondering if there is a way to search for the reference outside of specifying the exact field name compared to the field containing only "agf" since they are all using it.
Below is the search query:
<fieldPermissions>
<editable>false</editable>
<field>User.agf_Certified_Product_Owner__c</field>
<readable>false</readable>
</fieldPermissions>
In the field, I want to be able to find and delete the 5 associated lines from multiple files if they match "agf" in any combination. Something like the below:
<fieldPermissions>
<editable>false</editable>
<field>agf</field>
<readable>false</readable>
</fieldPermissions>
With any combination of agf in the field, delete all from any file it appears in.
Not an answer but too long for a comment
You don't have to? Profiles/perm sets don't block package's delete. Probably neither do reports.
You'd use your time better by searching for all instances of agf__ (that's with double underscore), should find fields, objects... used in classes, flows, page layouts etc. And search for agf. (with dot) should find all instances where your Apex code calls their classes marked as global.
Alternatively Apex / VF pages with dependencies on package will have it listed in their "meta.xml", for example
<?xml version="1.0" encoding="UTF-8"?>
<ApexClass xmlns="http://soap.sforce.com/2006/04/metadata">
<apiVersion>54.0</apiVersion>
<packageVersions>
<majorNumber>236</majorNumber>
<minorNumber>1</minorNumber>
<namespace>SBQQ</namespace>
</packageVersions>
<status>Active</status>
</ApexClass>
Last but not least - why not just spawn a dev sandbox and attempt the delete there? If it succeeds - great. If not - it'll list the dependencies that blocked the delete. It'll be "the real thing", it'll smite you even if your VSCode project doesn't contain all flows, layouts and thus could lull you into false sense of security. I'd seriously do it in sandbox and then run all tests for good measure, just in case there are some dynamic soql queries that don't count as hard, delete-blocking references.
After delete's done - fetch Profiles / Permsets from this org and the field references will be gone from the xml.
I know how to add or remove a store with PowerShell using Microsoft.Office.Interop.Outlook, but I haven't found any information about changing values.
I read https://learn.microsoft.com/en-us/office/vba/api/outlook.namespace#methods but I don't see a method available for setting properties.
Context: User's PST files have been moved from one path to another. I'm trying to avoid disruption wherever possible, so I'm writing a PS script to move the PST files, and then update Outlook with the new path.
Since removing and re-adding the stores will break user-defined stuff like rules, I'm hoping for a way to change existing store filepaths that will require no user action.
Is this possible at all?
As a second option, can I pull the existing rules, and modify them (or recreate them)?
PST store entry id embeds the PST path in it (you can see it in OutlookSpy - I am its author - click IMessage / IMAPIFolder / IMsgStore button, select PR_STORE_ENTRYID, click "..." next to the Value edit box).
If a rule includes a store id (e.g. copy / move message action), you would need to reset / recreate the rule.
I you don't want to remove / add a store, can reset the store location using ProfMan library (I am also its author) directly in the profile section in the registry. See https://www.dimastr.com/redemption/profman_examples.htm#example2 for an example on how to read PST paths. You can modify the script to set the path instead.
IS there a way to add/initate a comment ( e.g. $dom->createComment ... ) such that it comments out an entire block of xml tags. Basically I want to turn-off the content between the comment.
For example, it would look like this:
<TT>
<AA>keep</AA>
<!-- comment to blocking
<BB>hideme1</BB>
<CC>hideme2</CC>
-->
<DD>d's content is good</DD>
</TT>
Actually this question is a pre-cursor to my attempt to figure-out a method to be able to markup/label/identify the changes to an xml files in support of new client software functionality, but be able to have the ability to remove / back-out these xml changes in the rare event the client needs to fall back to the previous software version (and no I can't just simply point back to the original xml file because the client is allowed to make minor modifications to existing node text values). This is all going to be controlled via a perl script and LibXML's core modules (I can't use modules the client doesn't have).
So basically I've identified three possible types of xml changes as a result of new client sw functionality:
1.) ADD new element node(s) (typically to support new sw functionality)
2.) DELETE element node(s), or blocks of (would be rare, but never-the-less a possibility)
3.) CHANGE node text values (rare, but the new sw may require a new value)
For all three types, the client needs the ability to back out the changes. One thing I was thinking to use is ATTRIBUTES since the existing xml files don't use them. For example, for an ADD change type, I could include an atribute like 'ADD="sw version 4.1"' . This way if it needs to be removed, I could just simply have the perl script find those attribute strings and delete them (using LibXML methods). Same thing with CHANGE change type - I could use an attribute like CHG="newvalue_oldvalue", then again use straight perl (or LibXML) to switch back the value based on the contents of the attribute. The DELETE change type is giving me a problem though (as welll as the others lol!). I want to be able to "keep" the deleted lines in the xml file soley for the purposes if the sw falls back a version (at some late point the perl script could eventually cleanup/delete them).
I know this is a lot, I'm new to LibXML (but not to perl). I was just wonder if any of you have any thoughts as to how to go about it or seen anything resembling this kind of request ... I'd be grateful for any kind of advice! Thank you...
I'd like to create a dynamic view that only shows the files a user created/modified for a particular label.
Right now, I am listing all of the files in the label and comparing that with the previous label.
If I have to use cleartool to find the files, that is fine with me. I'd like the process to be more automated than it currently is.
Another option too is, can I simply see the diffs for a particular user? That way, I am more likely to understand the file's history. If a developer had attempted something one way and found that didn't work, it might be helpful to see that trial and error.
config spec:
#element * REL_2010.2.2.006
element * .../pgh_rel_4.0.0_dot_rel/{created_by(pp50773)&&lbtype(REL_2010.2.2.006)}
# first stop rule
element -directory * .../pgh_rel_4.0.0_dot_rel/{lbtype(REL_2010.2.2.006)}
# second stop rule
element -directory * main/LATEST
This config spec doesn't fetch my changes - It fetches empty directories. It is also important to note that while I made the changes to the actual file, another guy is responsible for applying the label weekly. So, if it goes by whose name is on the label, that won't work.
If I remove the created_by constraint, it works fine listing all of the changes for the label, but I want only files in that label for a given user.
Walter
According to the version selector rules, you can do that, but I would recommend:
2 dynamic views (easy to setup and refresh, since their content is not downloaded on your hard drive, but accessed through the network)
one one for one label
one for the other
to not forget to add stop rules for directories (if directories are not created by your user, they won't be selected, meaning your view won't be able to select any version within it.
The config spec for one of those view would be something like:
element * .../MyBranch/{created_by(myuser)&&lbtype(MY_LABEL)}
# first stop rule
element -directory * .../MyBranch/LATEST
# second stop rule
element -directory * main/LATEST
When you have two views correctly configured, you can compare their content with a tool like WinMerge.
For example, instead of writing the following:
element * .../my_branch_01/LATEST
element * .../base_branch/LATEST -mkbranch my_branch_01
I would want to write something like this:
MY_BRANCH=my_branch_01
element * .../%MY_BRANCH%/LATEST
element * .../base_branch/LATEST -mkbranch %MY_BRANCH%
Is this even possible? What is the correct syntax?
The only native way to do this in ClearCase is to use attribute within a config-spec.
According to the version selector rules, you can make a "selection by query" rule, based for instance on an attribute:
element * ...{MY_ATTRIBUTE_NAME=="aValue"}
would select the LATEST version on any branch with an attribute 'MY_ATTRIBUTE_NAME' with 'aValue' in it.
That mean you need to change the attribute value on the old branch, put it on the new branch, 'cleartool setcs' your view again, and you should have a new content based on a new version selection.
Not very straight forward, but it could work, except for the mkbranch part (which needs a fixed name).
Regarding GeekCyclist's answer, a few comments:
The solution to include a common config spec can work for Base ClearCase solution, but:
need to be in a share available by all concerned developer
the setcs is indeed necessary to Ccuses the view_server to flush its caches and reevaluate the current config spec, which is stored in file config_spec in the view storage directory. This includes:
Evaluating time rules with nonabsolute specifications (for example, now, Tuesday)
Reevaluating –config rules, possibly selecting different derived objects than previously
Re-reading files named in include rules
all the other developers need to be notified when the common included config spec file changes (there is no native notification included in ClearCase)
If you need to have one "environment" (i.e. one "view" or workspace) with a variable content (depending on a different branch), you need to define a symbolic link (or a windows subst) pointing to different views (each with their own config spec)
That way, you only have to change the link (or the path subst'ed) in order to change the config spec associated with a given fixed path.
It's been a while since I worked in ClearCase (we switched to Subversion), but if I recall correctly there is no way to do this native to ClearCase.
You could use or write a script generator that would create your spec file and then include that in the actual spec:
element * CHECKEDOUT
include scripted_file_output
Then run
cleartool setcs -current
The problem with this approach is that I believe the include spec would need to be regenerated and the cleartool setcs run whenever you change the value of MY_BRANCH.