Concurrent editing in Web Designer overwrites each others edits
In VertiGIS Web designer concurrent editing of the same web app will overwrite each others changes.
I.e Admin1 and Admin2 opens the same Web app in the designer with two different administrator accounts at the same time. Admin1 makes changes to the app and saves the app. Admin2 then makes different changes to the app, saves the app. Reloading the app in designer for both admins will only show the edits from Admin2. Edits from Admin1 is overwritten.
In Geocortex Rest Manager there can be only one user editing a site at any given time. And a padlock symbol indicates that a site is being edited through the Rest Manager.
There should be some kind of similar behavior for Web Designer preventing administrators from issues that may occur from concurrent editing.
NB! The same goes for VertiGIS Workflows.
-
VertiGIS... I spent some time thinking about this and writing about how Portal is different than a custom web application and reinventing the wheel and blah blah blah but I ended up with a hypothetical which seemed feasible.
What about holding onto the Portal Item last modified timestamp when opening an Item in Designer, then checking the existing Item timestamp before saving? Looks like there's already a check to ensure the item is available. Then warn Designer users about the mismatch and let them sort it out from there, maybe offer a button to open the current version in a new window. Thoughts, @...?
2 -
second this. The padlock was a great feature of the Geocortex Manager
1 -
Adding my Gareth weight to the pile, thanks for tagging me Zack Robison. Your idea makes sense, though it doesn't truly "lock" the item in the same way the Geocortex Essentials Manager did at the REST endpoint level. I think it's technically feasible, though I can't speak for the product team. To me, this is a UX level solution to a data management level problem, which I think historically is frowned upon by developers. I imagine this would also be weighed against the idea of adding new code that could break should Esri's underlying model change.
Anyways, as a member of our Solutions Engineering team I've certainly run into scenarios of multiple people editing the same Studio app and know the headache it can cause. The question is, is the development effort of implementing a solution and risk of creating other knock-on issues worth it? To that I'm not sure.
1 -
“To me, this is a UX level solution to a data management level problem”
100%. Is it worth it? Maybe?
If such a thing didn’t come with a rudimentary code comparison then users (devs) would most likely still want/need to communicate about what they were doing to the item in question. I imagine implementing a code compare would be a more expensive task, so let’s ignore that and figure a simple implementation… to me the big UX benefits seem like
- concurrent editors unaware of each other would be alerted of potential issues… this could reasonably save modest dev time in edge cases
- concurrent editors could discuss or compare WFs before overwriting each other’s work, though they’d still need to figure out the differences between an Item’s forks themselvesI think most WF dev teams are pretty small so assuming they communicate a bit they probably only benefit from such a feature occasionally. That said, I think the most likely time to bump into it is when a team is just starting on a project and isn’t familiar with the issue (itself more of a Portal problem than a VS one), which might be better thought of as a training/barrier-to-entry issue. I see a good amount of this but grain of salt I do a lot of VS implementations concurrent with orgs which are simultaneously implementing Portal. Myself, I feel that’s be worth a *little* time, but not much… that’s just me though!
1 -
I definitely see the value in what you're suggesting, Zack Robison! From my experience, most enterprise-grade web applications are worked on by multiple people so therefore we need to think about the use case of multiple contributors to a single application.
(part of) the issue is we don't control the data model here, Esri does. Curiously, I haven't found much guidance or discussion around this use case on their community. Have you seen anything around this?
0 -
Bump, and am happy to help with design where I can!
0 -
Noticed this morning that Sharepoint has features for this, if that helps as an example.
0
Du måste logga in om du vill lämna en kommentar.
Kommentarer
7 kommentarer