Latest Contributions by FrankMancini

Prevent a survey from from opening in the web app/browser.   Use Case: published S123 form contains logic that only works in the Field App. force user to open form in Field App.   FieldMaps has the option to 'Hide in Field Maps mobile' or set the web map item's "typeKeywords": ["FieldMapsDisabled"] parameter.  A comparable configuration option to disable web form access under the Collaborate > Share Survey or Settings menu would be useful.   A comparable Survey123 "typeKeywords" option like "WebAppDisabled" would be also be useful.  ... View more

Hide a survey from the 'Download Surveys' list in the Survey123 Field App.   Use Case: Portal Group with access to 2 different S123 Forms. 1 form should only be used in the iOS Field App. 1 form should only be used in the Survey Widget of an Experience App. I would like to prevent users from downloading the Experience S123 form to the iOS Field App. Same user group requires access to both forms, so sharing alone cannot accomplish this.   FieldMaps has the option to 'Hide in Field Maps mobile' or set the web map item's "typeKeywords": ["FieldMapsDisabled"] parameter.  A comparable configuration option to disable download for each form under the Collaborate > Share Survey or Settings menu would be useful.   A comparable Survey123 "typeKeywords" option like "FieldAppDisabled" would be also be useful.  ... View more

Is it possible to hide a survey from the 'Download Surveys' list in the S123 Field App?   I have a use case where a Portal Group has access to 2 different S123 Forms. 1 form is intended to be used in the iOS Field App and the other should only be used in the Survey Widget of an Experience.  I would like to prevent users from downloading the ExB form to the iOS Field App. Same user group requires access to both forms, so sharing alone cannot accomplish this.   FieldMaps has the option to 'Hide in Field Maps mobile' or set the web map item's "typeKeywords": ["FieldMapsDisabled"] parameter.   Does Survey123 have a similar option?  If not, it needs one.  Could probably also use the opposite option to restrict use to the Field App only.  Should apply to all Field App platforms (iOS, Android, & Windows)   ... View more

Running into issues automating version reconciliation using arcpy script scheduled nightly on Windows Server.  ArcGIS Desktop 10.6.1 Enterprise Geodatabase (SQL Server) with multi-generation version tree (3+).  Believe Windows and SQL Servers are 2016, but cannot confirm at this time.   Would like to automatically RECONCILE ONLY all versions nightly as maintenance step before Compress. Reconcile will identify conflicts and notify version owner who will manually resolve the following day.  We only want to resolve unique conflicts one time while the version exists and until new (not already resolved) conflicts are generated.  Want to avoid having to resolve the exact same conflicts every day. Reconciling with arcpy.ReconcileVersions_management(): by attribute, no post, abort on conflict. Versions can exist from days to weeks as needed. All Edits are manually reviewed and posted as needed.  Versions are deleted after posted to parent as long as other child versions do not exist.    Starting to think that the automated behavior I want is not possible, but if anyone else has run into this issue and figured out a workaround, would appreciate some advice because I am out of ideas.  Please read on for more detail...   RECONCILE ORDER Initially reconciled all versions with DEFAULT, then realized I was unintentionally creating conflicts.  Thought (incorrectly) it might have to do with the order of reconcile decided by the EGDB, so came up with a way to control for that. Controlling reconcile order by first generating a list of versions with children sorted by parent version creation date (top down - oldest first, newest last).  Oldest version reconciles with its children.  Those children then each reconcile with their own children, and so on...     ISSUE #1 Legitimate conflicts identified by automated script are reviewed and resolved by editors the following day. Automated script then re-identifies same (and potentially new) conflicts on the next run. This is not exactly* how the reconcile / identify conflict / resolve process works manually using the Reconcile Tool on the Version Manager Toolbar in ArcMap.  Once an editor identifies and resolves a conflict with its parent and then saves the edit the same conflict will not be identified the next time the editor reconciles their version with its parent.  * Difference is that the editor can only reconcile with the parent version using this tool, not with grandparents, great-grandparents, etc.. as is happening in my script.     ISSUE #2 Illegitimate conflicts identified by automated script if the child edits same record as parent version.  Again, this is not exactly* how the reconcile / identify conflict / resolve process works manually using the Reconcile Tool on the Version Manager Toolbar in ArcMap.  A child version can edit the same record as its parent without generating a conflict, it is just a standard version change. Which brings us back to ISSUE #1.   Scenario:  - Analyst creates a new version off DEFAULT, makes an edit (adds a new polygon based on valid dimensions in approximate location) and notifies Manager to review edit. - Manager creates a child version of Analyst's edit version and makes correction (moves new feature to correct location).      NOTES I understand that I am triggering these conflicts by starting at DEFAULT (oldest version) and reconciling down generationally.  No matter how I think about it though, I simply cannot wrap my head around reconciling (no post) from the bottom up. I did test the bottom up approach though... after conflicts were manually resolved, the automated script did not generate conflicts on the next automated run, but (as expected) conflicts were again identified as described above on the next run. I get that technically these are all “conflicts” by definition, the same record was edited in multiple versions, but once they are resolved they would (ideally) not need to be addressed again. I can also see the argument "how would the database know" that subsequent conflicts are/are not the result of the exact same edit.  I feel like this scenario could be better handled by reviewing the Version Change log or whatever QA/QC process is in place at the organization.  My assumption is that conflicting records are determined on the fly when the reconcile tool runs and records of conflict resolution are not stored anywhere in the geodatabase tables for subsequent runs to refer to? IF the answer is simply ESRI Versioning doesn’t work this way, then good to know not to put any more effort into this rabbit hole.    HELP? If anyone else has encountered similar reconcile automation issues or if anyone notices a flaw in my logic or process...  Please reach out to me, would really like to figure out a better way if possible.    Thanks in advance! ... View more