nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Allow Export for all layers

DanCopKac

So my client was just watching me work through one of their apps during a casual phone call/share screen review, and they requested that the end users would not be able to export the data from the app - for all layers, approximately 70 layers.

So I tried looking for an option to turn off all the layers at the same time. After a quick search, the option is nowhere to be found in Experience Builder, so I started turning off the Allow Export option for all the layers one by one, and sometimes having to backtrack because I'd forgotten where I'd left off, since many of the layers are many hierarchies deep.

As the client continued reviewing the app, he started to ask, "Do you have to do this for each and every layer individually?" in a completely astounded and dumbfounded manner. I sheepishly answered that yes, it seems so.

They got upset and said, "IS THIS WHAT I PAY YOU FOR? I PAY YOU FOR YOUR GIS KNOWLEDGE AND EXPERTISE, NOT TO SIT HERE CLICKING THE SAME BUTTON FOR 30 MINS! MY GRANDMA CAN DO THIS JOB! AND YOU HAVE 8 MORE APPS TO GET THROUGH! I'M NOT PAYING FOR THIS!"

So yeah, I felt super embarrassed because I had recommended this technology and Esri software suite to him. And I was already going to charge them 4 hours of work for disabling export on all the apps and all the layers.

So when are we getting a DISABLE EXPORT ALL LAYERS button?

Find more posts tagged with

Accepted answers

Shengdi Zhang

Hi @DanCopKac ,

This feature is supported in the latest February AGOL release.

Regards,

Shengdi

All comments

Shengdi Zhang

Hi @DanCopKac ,

This feature is supported in the latest February AGOL release.

Regards,

Shengdi

DanCopKac

I found my own solution! Since the team didn't provide a workaround, I tweaked the boolean so that all data sources default to disallow export, but the setting can still be manually changed.

If you are on Developer Edition and suffering from the same problem as me, you can follow these steps:

In the installation folder navigate to the following file

client\dist\jimu-core\data-source.js

find the line

Promise.resolve(!0))}return!this.getDataSourceJson().disableExport

change it to

Promise.resolve(!0))}return this.getDataSourceJson().disableExport

Now all layers will default to not allow export when the config.json value disableExport is not yet set. Note that anyone looking in the config.json will get confused because this flag will no longer make sense.

Additionally, this creates chaos in the builder because the toggle in the data panel still says "Allow export". So I went ahead and changed this text to "Disable export" as well so the toggle button makes more sense.

That can be done by following these steps:

Navigate to

Client\dist\builder\widgets\data-source-setting\dist\runtime\widget.js

change

allowExport:"Allow export",

allowExport:"Disable export",

Now you don't have to spend hours or days wading through the data panel to disable exports for each of your layers one by one!

If you upgrade Experience Builder, you'll have to do this again, of course, and they might also change the code so that this doesn't work anymore... But hopefully instead they'll just spend their time building this simple feature instead of trying to disable this fix.

TimWestern

@DanCopKac wrote:
Is that a factual statement though, really? That Experience Builder is not intended to be feature complete? And so we should regard it as such?

I want to be careful. Because Experience builder solves some things, it introduces some new considerations, but you used the word 'intended', I didn't mean to imply that it was intended, but I have seen enough traffic in the community that suggests in the eyes of many of the users, It still lacks some things compared to the predecessor. I have seen people suggest it was released and switched to before it was 'complete', but complete is a nebulous term in software. (in other words, it often depends on who is talking, what they mean) New features can be added all the time, and though EXB is the a replacement for WAB provided by ESRI, as you described its not an apples to apples comparison in all facets.

I think its good enough for a lot of things, I would hesitate to suggest it doesn't have more that needs added to it, not just because GIS software in general has a lot of areas it covers, and because software is never a fixed target, its always moving.

I don't work for ESRI, so I can't tell you what but they have said. I'm a little new to the community of EXB, but when I read some of the community traffic since it was first introduced, and compare it to what's been going on in other nodeJS spaces (namely React and Next.JS) There are a lot of similarities, though I'd suggest EXB is a bit behind both.

I honestly don't know that lifespan, for a software used to build web interactions, the way EXB does, can really be compared to the life span of other off the shelf software (say Microsoft Office for example)

Unless react gets retired as a primary component, I see no reason EXB can't continue to grow for another 20 years, frankly. (Note that the .Net Framework has been around since early 2002, and is still going pretty strong 22 years later.

Now as to the ETL mention. UI often suffers because of what happens beneath it, as a Software engineer and developer for 20+ years, I can attest to that. In my little bit of time using EXB, and querying in layers, It doesn't take much for me to imagine situations where the browsers in which they run, can tip over. Some of that is preventable in the custom code world though.

In all my time developing software, whether its for desktop, the web, or running inside a platform like ArcGIS, one constant remains. People who rely on its use, but do not have the skills to build it, often expect things that have not been thought of to include yet. The amount of buzz word seeking and assumptions drawn by those who decide what software to license are not always as informed technically because in many organizations the leadership is not as technical as the people they oversee. (That isn't always the case, but even if they are, the people they report to often are.)

Not sure how this helps your question. It's frustrating when someone you do work for, doesn't seem to understand what it takes to do the work they ask for.

DanCopKac

Is that a factual statement though, really? That Experience Builder is not intended to be feature complete? And so we should regard it as such?

The Functionality Parity matrix put out by Esri seems to indicate that Experience Builder is a thoroughly competent replacement to WAB, and also since WAB is already in Deprecation status. Don't get me started on how the Function Parity matrix even claims that a replacement widget has parity, but really doesn't. Like how the ExB Draw widget still can't draw text.

The community keeps using this excuse, that Experience Builder is still a budding creature, an infant juxtaposed against its cousin, but do the devs really believe that themselves? They certainly don't seem to promote it that way. Experience Builder is, what, just about 5 years old now?

WAB was released 10 years ago in 2014, and the first version retired in 2023, meaning it had a lifespan of 9+ years. Experience Builder is already more than halfway into its (potential) lifespan. I wouldn't really consider it fledgling at this point.

And what exactly does a server's processing speed and ETL techniques have to do with a banal UI issue? I'm not sure I understand your point?

DanCopKac

I tried digging into the config.json but lo, the problem is that the disableExport flag for the data sources isn't even generated until the setting is toggled (where it then adds the line disableExport = true). So I can't even do a find and replace to set the flag. Any workarounds from the team?

TimWestern

To be fair (I don't know the background of the people you build for), sometimes the people in the Boss's chair are not as technical, don't really have experience with such technology, and they think if something seems obvious or easy that it should already be there. The reality is, they may mean well, but they don't realize that software is always growing and changing, and with Experience Builder, because its still not quite 'feature complete' compared to where WebApp Builder was the thought that this works, but may not be tuned may not occur to such an individual.

Also, GIS often involves a lot of ETL (Extract/Transform/Load) functions that move data from one data source, manipulate it, and then load it to another location. A lot of the data sets we work with are not exactly 'small', and no matter how fast a server is, some processes still will take time.

kxu

Hi @DanCopKac,

Thank you for pointing this out. We will look into it and keep you update. Thanks for your patience.

Thanks,

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.