The offline package can be used in situations in which the web installer cannot be used because of lack of Internet connectivity. This package is larger than the web installer and does not include the language packs. We recommend that you use the web installer instead of the offline installer for optimal efficiency and bandwidth requirements.
Virus Scan Claim: Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help prevent any unauthorized changes to the file.
Fixed a handle leak during creation of a Window in WPF applications that are manifested for Per Monitor DPI V2 Awareness. This leak may lead to extraneous GC.Collect calls that can impact performance in Window creation scenarios.
This is a catastrophic change of operation for this App. We will certainly will not get an IT Security clearance for syncing any of the companies details to Postman (and tbh we do not want to). There are critical details in the Requests, Examples, Tests and Environment, which just cannot leave the company.
You can check out our Trust Center to learn more about how Postman makes sure your data is securely saved and synced: Trust Center Postman
FWIW we already have companies from the banking or government sectors trusting us (cf Case Studies).
Our genuine concern stems from the potential exposure of highly confidential business logic, especially evident in pre- and post-request scripts when using cloud platforms. These scripts are of a sensitive nature and, as per our protocols, must remain confined to our company or certified subcontractors who have undergone stringent checks for security and compliance.
Further deepening our reservations is our understanding that every request made via Postman routes through your servers. This implies that Postman might have the capability to access and potentially view the data, some of which is critically sensitive.
Lastly, while there exists a some other tools like Thunder Client, Insomnia, and SOAP UI, none match the prowess of Postman in terms of features and user experience. It presents a daunting task for us to contemplate migrating from Postman to any other tool, considering the advanced integration we already have in place.
It is our sincere hope that these concerns resonate with you, especially in the realms of regulations, compliance, and confidentiality, when envisioning a cloud-based product tailored for large-scale enterprises.
Looks like time to move on from this App. I can see this app will now lose users, which will lead to less incentive into its development, and this app will be finally taken to a grave and put to REST in an orange coffin.
Amen.
If you are fortunate like me, I still had the installer from an older version which I used to re-install Postman and add the following to my Windows hosts file to prevent automatic updates (which occur even with the Auto Update setting turned off).
This contains information about how Postman protects your data and it provides a link to our Security & Trust Portal, where you will find additional details about our product security, privacy, compliance, and reliability information.
Probably just missing a step, but I keep missing it consistently. I have a Traditional versioned dataset in our Portal. The Web Map and layers is configured for sync with a version per user. Creating offline area, editing and syncing all works fine. But when I go to delete the version created for this user I get the error "Operation not allowed on a version with dependent children." I know how to fix this in the SQL Server backend, by manually deleting all the dependent children first. But am I missing a step in a typical offline editing process? thanks!
Posting a final follow-up. I submitted a support ticket with Esri and went all the way through a number of very helpful support departments from Field Maps to Enterprise, finally landing on the SDE / DB team. This is a synopsis of how far we got.
It seems like my process is generally correct, but somewhere along the way when I remove an Offline Area from Field Maps the action to remove the child SYNC versions of the offline editing version is not making it to the back-end and so those child versions are not being deleted.
ArcGIS Pro only displays the main offline edit version, a child of DEFAULT, but does not display the other children of that version. Trying to delete the main offline edit version results in the `160361: Operation not allowed on a version with dependent children.` error, which is recognized but has no solutions, here.
So the only solution we could identify was to access the SDE_VERSIONS table in the back-end DB and manually delete the dependent children of the main offline edit version. So in the screens below version_id = 173 is the main offline edit version that is visible in ArcGIS Pro and which cannot be deleted in Pro. The additional SYNC versions below that are all children of that version and these are not visible in ArcGIS Pro. These versions should be deleted when the Offline Area is removed, but for some reason in my workflow that is not always happening.
So. I manually, and carefully, write out the DELETE statement for each of the child versions, double checking that it is part of the version tree of version_id = 173. Extreme caution here since this example on our dev environment is relatively easy and there are no other versions happening at the same time. In production, it is more likely that there are other versions mixed in among these, so it is an arduous task. Obviously be careful here because DEFAULT is right there! So we felt there was no "smart" SQL statement way to perform this, no range or JOIN, and that each WHERE should be typed out manually and deliberately.
With the versions deleted the, there are no more dependent children of the main offline edit version and that version can and should be removed in ArcGIS Pro only, don't delete it from the DB back-end!
I'd say this situation comes up for me about 80% of the time. So I will continue to test this out. 20% of the time when I remove an Offline Area after offline work is complete and the rec/post have been performed, I am able to delete the main offline edit version in ArcGIS Pro as expected without this back-end work.
At this point I am wondering if there is an issue where Field Maps isn't connected to our Enterprise Portal prior to removing the offline areas. If the credentials are somehow "stale" or if the iPad isn't fully connected to the network and signed in to Portal.
The sync version should be automatically deleted when the mobile user uses Field Maps to remove the offline area from their device, assuming the mobile device is connected to a network when the remove area option is invoked.
@Sean_Haile I have tried this again with another account and another iPad and I get the same result. I agree that what you said is what is supposed to happen. Remove the offline area, rec & post in the office to DEFAULT, and then be able to remove the version, but I keep getting the error. I updated Field Maps to the latest version on my iPad and get the same results. I think i was followed the guidance on this post. Guess I will try recreating the service and see if that does it.
@Sean_Haile I re-read your comment, I do not believe that the sync version would be deleted when the offline area is removed. Deleting the version is done by the manager or user after confirming that any edits are sync'd rec/posted, and the offline area is removed.
It seems that the issue comes up if I try to delete the version and there is still an offline area. This throws the error as noted, but can no longer be fixed in ArcGIS Pro regardless of what is done in Field Maps (e.g., removing the offline area, adding a new one, removing, etc.,). Trying to delete the version when there is still an offline area out there (for example, forgetting about that offline area, forgetting about a device) seems to orphan a replica that can no longer be removed unless I go into the SDE_Version table in the DB backend and remove the versions.
b1e95dc632