Well that was silly of me. I didn't realize AppCommonModule was not in scope of subheader.module; importing it solved my issue.
Thank you!
D'oh! Can't believe I didn't think of that; you're 100% correct, thanks for a great product and great support, @ismcagdas
@Zony, thanks for your reply. Yes, they do. I see them immediately in the database and also via an application service reading the same values.
Thanks @ismcagdas I re-ran npm run build, did a full clean+rebuild, and that solved my issue. Appreciate it!
I recently added azure blob storage to my application, with container generation based on the tenancy name. The approach I took, in hindsight was probably overkill. But I went with a generic implementation to allow for additional storage options in the future. I created entities for ConfigurationProvider and ConfigurationProviderParameter - so in this example Provider would be "Azure Blob Storage" and Parameter holds entries for things like DefaultContainerName and ConnectionString. Then entities for ConfigurationEntry (IMayHaveTenant) and ConfigurationEntrySetting holding tenant-specific values for my provider parameters.
After that point I have abstract classes for my providers, and an implementation of that base class for MicrosoftAzureBlobStorageProvider, which handles the comms to/from azure. I should note I'm using Abp.Dependency.IIocResolver class to dynamically inject the class needed. The class name is storage in the ConfigurationProvider table, e.g. 'Xyz.Factory.Storage.Providers.MicrosoftAzureBlobStorageProvider, Xyz.Application'.
If you are not planning on switching between providers then you could greatly simplify this by going straight with AppSettings entries for your azure configuration
Upload references are stored in a separate table. So as to not continuously ping Azure, I save to my db table things like contentType, fileSize, directUrl to the file (assuming it's in a public container), ETAG, and some basic metadata (dimensions for images, for example).
The nice thing with Azure is if your containers are public, you can save the path to the file and serve it directly to a user to save on your bandwidth. If you are working with blueprints you may need a little additional security, in which case you can mark your container as private, still store the direct path to the file on your end, and use the azure API to essentially stream the file to your server and then spit it back out to the end user. That way you can be sure files are protected against unauthorized access to anyone knowing the url.
hope that helps!
You would need to disable the Appropriate data filter in your unit of work. See https://aspnetboilerplate.com/Pages/Documents/Data-Filters#imayhavetenant
Awesome, thanks! I'll apply that now and plan on jumping to 8x shortly. Appreciate your help.
@maliming I was actually able to track this down to how I was handling datatables inside of modal windows:
$(document).on('shown.bs.tab', 'a[data-toggle="tab"]', function (e) {
$($.fn.dataTable.tables(true)).css('width', '100%');
$($.fn.dataTable.tables(true)).DataTable().columns.adjust().draw();
});
I added this code due to an issue with datatables in hidden tabs not spanning the width of their container. Removed the code and problem resolved itself.
@ryancyq, thanks for your reply.
The solution I came up with this morning, which works but is not the most elegant -- I've modified ModalManager.js to look for the existence of either an UnauthorizedException or UserFriendlyException in the html response. If found, I parse out the message and display it, rather than the default InternalServerError.