We are working with an existing SharePoint solution for a Company (its an Intranet). Now, the company is splitting into two and so is their intranet. Each company, of these two, from now on will have their own Intranet. So, idea is to split this Intranet (which is just a web application) into two web applications. But wait, these companies will also have some information to share in between. So, the idea is to put the shared information (Administrative stuff etc) into a separate web application. So, we have three web apps so far.
Previously, Company's intranet was managing the data of about 50 facilities in the form of Subsites. Now, according to new design, each web application will have 25 facilities each. In other words, each company will have 25 facilities. But, problem is that each facility is having large amounts of data almost 5GB+. So, its not possible for me to put the restriction quota at the site level. Although, we can put restriction on the size at SiteCollection level (as per my understanding). So, the idea so far is to create one site collection for each facility, it means we will have 25 site collections in a web applications. Navigation could be a nightmare. But, can we solve navigation problem with managed path etc?
any other suggestions/improvements will be warmly welcome and appreciated! Even your little comment may help me to improve my design ;)
In the proposed design, you will have to manually setup the navigation (managed paths will probably not help unless you want to have something other than /sites/ in the url).
I do question why you now have to split each of the facilities into their own site collection when, before the split, subsites worked. I would only recommend each facility be a unique site collection if you can forsee being asked to move facilities between the two new companies.
Related
I work with a large university and we track hundreds of subdomains and we also have a few apps. I'm looking for the best solution as we migrate to GA4. (I know, should have been done long ago.) We currently have 20+ Properties which all contain up to 25 Views, each configured to track individual subdomains or apps and we grant user access to these individual Views.
With GA4, Views are deprecated. I'm wondering if anyone has dealt with this type of challenge and how they split up subdomains. We need to keep one account (if possible) and a general plan of action for breaking up all these domains so we can streamline the Analytics data for our end-users.
We do use Google Tag Manager as well.
So far, we have one "main" GA4 property with a single datastream for the root web. The app side is not configured. We also have about 3 other properties setup for individual big players (i.e. colleges or departments which we know will need lots of customizations).
I'm wondering if we should make more properties with multiple "web" datastreams for the many subdomains, but then, how might this affect user engagement with this new Analytics model. Should we handle this in a completely different way.
You don't make properties for stakeholders. You make properties for tracked activity types. Duplicating the tracking is not a good solution.
You don't have the views, but you have the hostname dimension which you can use to filter reports. Feel free to make hostname-based segments and teach your stakeholders use them.
Finally, native app tracking is done through Firebase. Firebase can then be linked to GA4 as its own stream. Better to keep in the same property you keep the web data.
The general rule is: Don't make additional properties unless you know what you're doing. Additional properties will increase complexity on both ends: the collection and the post-processing of data. Increasing complexity needlessly is just pure incompetence that will make many people frown upon it when they inherit your design.
I work for a smaller record label company that has distribution and office locations in the UK and US. They want to join the sites into one and use geoip to determine what content to show.
The UK has rights to show content that the US doesn't, orders in the US go to different distributors than the UK. Basically in almost every sense the functionality of the content is desired to work different. Licensing for example the UK uses different licensing with a third party and the US handles it themselves.
The stack plan was nodejs api as a central hub and SPA angular/javascript front end with an admin app under a sub domain.
Q1. I imagine for SEO it would be beneficial to have a .co.uk and .com domain instead of serving all from .com and changing content based on geoip?
Q2. I was originally planning to serve from a single API resource and return data attributed to different country/shops. But functionality wise there are different sections that use different functionality, such as licensing will function different in UK than it will US. Should the sites and data be independent, or should I try to make it work as a multitenant app and work through the different functionality based on the domain name? If I make a multitenant site it doesn't seem in areas of functionality that data will have the same structure.
Are you building that site yourself? It's not sounding like a one man job to be honest. The correct solution sounds like you need to break the two sites apart, however if you're a 1 man team then that's a lot more work.
To do both sites with one infrastructure you'll need to abstract it in the correct way and probably put on it a few layers that will decorate and template it. I wouldn't advise that simply because node.js apps were meant to do a small functionality very well, and not become huge apps serving multiple domains.
I recently finished one of my first AgilityJS projects, which is a web-based file browser that lets you create and manage folders and files, and navigate around the folder tree. I followed the various AgilityJS recommendations regarding the design and ended up with all my HTML and Javascript in a single Javascript file.
Now, I would like to provide a "read-only" version of this app which does not have the ability to add/edit/remove files and folders. I'd like to have 2 user types on the website, one type which can only read the files and folders, and another user type who can administer.
My question is, how do I proliferate these permission differences to my AgilityJS app? I know how to secure my endpoints and operations on the server side, but I'm wonder about the best way to do this on the client side. Should I create a separate version of the app with a limited set of functionality? Should I simply hide certain buttons/features? Are there theories, frameworks, etc.? which deal with this issue? Any point in the right direction would be helpful.
LOL - probably one could write books about that topic. Some very basic ideas:
I would start with the philosophical debate according to MVC. There are people argue with the help of MVC that any piece of code and also any piece of data model should never be implemented twice. Business logic and model to the server. The opposite view is focussing on serving users at any cost - even if that means to double maintain code or the model for the sake of avoiding extra round trips. The way in between defines a master source for business code and model and makes sure to follow on other places that leading master (the master will be changed first). Take your choice. Your answer to that question results into boundaries for how the user interface can/have to look like for the user.
You need to think by hard about a permissions concept. Looking at Microsoft I would assume that they invested for all their applications a couple of dozens man years to make up the permission concepts. The ideal permission concept very much depends on your application. So it is close to impossible to work this out without knowing at least a very little of your application. However the permission concept has to come up with policies deciding on roles, groups, access rigths, access levels, context driven permissions (eg. based IP address), permissions black or white listing (permissions each user has at creation). An example from Microsoft: http://office.microsoft.com/en-us/windows-sharepoint-services-help/permission-levels-and-permissions-HA010100149.aspx
Data on the client is not secured!!! Whatever you do on the client, be it data hiding, encryption, compression... - if this is done on the client there are ways to read the data (even by disabling the data manipulation) or by reverting those. Somebody can send data to your server, where the client should not even have given an update form could be implemented by hackers. So as soon as you start to implement permissions make sure, that for all data you send to clients users are permitted to read and that you inlcude permissions checking for each time you add/update data to the database.
What is the best way to manage users with PirhanaCMS?
I would like to prevent some users from adding content (posts etc...) in some categories and prevent that some sites be listed for some users. (For people who don't know it, PirhanaCMS is a micro CMS programmer oriented).
I would like to use the sites features because I'm working on a project in which I'll have a "network" of several sites managed by different entities of an organization. I would like that each entity be only able to see its own site but that the big organization at the top be able to manage every sites. Moreover, within a site I would like that some users be only able to edit some part of the site.
Are these features built-in ? Otherwise what is the best way to implement them myself around the CMS ?
I am using ASP.NET MVC 4 and EF5.
If you take a look at System > Permissions in the manager area you can see that there are permissions you can give to groups for different parts of the manager interface.
There's however currently no built in support for restricting access to different site trees, but you are free to add a feature request for this at GitHub or maybe participate by implementing it and sending a pull request!
This has been something I have been trying to work on for a good long time. It first started with Prestashop as an integration with other scripts or pieces of the puzzle I needed to make for an overall website. I am currently still using Prestashop as my webstore but have since switched to Magento.
I switched to Magento because of it's complex flexibility and because overall I think it is the best solution, best backing and best overall eCommerce script to go with.
That being said, the same issues I was having with Prestashop appear to be the same I will continue to have any in aspect that I try to integrate things together in perfect harmony.
I have Magento setup, as the main portion of the website, and inside Magento in sub folders I have Wordpress installed in a folder called "articles" and I have also went with FluxBB as my message forums because of it's simplicity in not having a crap load of bloated extra features that I could care less about and that is in a sub folder called "forums".
From this point, we know that Magento, Wordpress and FluxBB all have their own way of managing users; creating, managing, and tracking them.
What I am wanting to do is find the best way to fit these three and more together for my website to make the experience for the customer as smooth and as functional as possible. After emailing the ever talented and helpful Alan Storm, he told me the best solution he was aware of working was to make a third party user management that they all point to and it manages the customers authentication. I do believe his thoughts may be the best but I wanted to put this out there here on StackOverFlow and I may post this on Magento as well to get the broad scrope of magento developers and smart guys that like challenges.
I have several thoughts, none may work, some may work half ass, or one may just be something workable. But first let me tell you what I have accomplished so far. I have done the necessary steps to integrate my overall design for the header and footer, so essentially Wordpress and FluxBB are wrapped and are contained inside Magento's outer design layer. So with that being said I have also made it where Magento will check the session to see if the user is logged in to Magento or not by saying "Hello Guest" or "Hello User". This is where I have hit a stopping point because I am out of my depth and would like assistance, whether it is something we create together out of pure challengeness or someone says if I pay them they will help me, either way I would like this accomplished. If and when I get the code figured out whether by means of paying for assistance of a group effort I would like to make it freely available for others to use the concept for their own projects.
Brain Fart #1:
Adjust the user tables for both Wordpress and FluxBB to conform more to the structure of Magento, as for the password and username/email login portion. The rest of the fields can respectively stay as they are for post counts, and etc.
From there, I would like to figure out which class in Magento does the actual input into the database when a customer is created out of registration. When I find that code, I would like to extend upon it the ability to copy the user credentials into the other two tables in the database for Wordpress and FluxBB. If necessary it can just be an added couple of fields to Wordpress and FluxBB if that seems like a better idea and yes I do mean the actual encrypted password that Magento creates, I want this to be secure as well.
From there, when we know that a customer registers with Magento the data is copied over to the other two tables then we at least have made progress, whether this progress will actually work, is still to be determined.
We then disable the login/logout and registration links in any way that we can from Wordpress and FluxBB because they will no longer be needed because we want the user to register, login and logout through one location which is Magento.
Then comes the fun part in my eyes, keep the damn session going throughout the entire website as they order products, review wordpress articles and possibly leave comments, send to friends and etc.... as well as post topics, replies and etc in the FluxBB capacity.
To me this is where the creating the fields or adding the data from Magento's customer registration comes into play, I can make it check to see if they are logged into Magento already and from there we may be able to have it validate itself. This may be over kill or this may just be how it needs to be done. But to me if the credentials are located in all three databases then they should be able to be validated by changing the code in Wordpress and FluxBB or adding code. And Yes I am aware that we will also have to do something about Profile Editing and Password Editing if a customer so desires to change their information.
But that is my first thought on this whether it is the right decision or not, I would like hear from the vast knowledge of people here who have more experience and knowledge than I get with Magento, PHP and everything else.
Brain Fart #2
This illogical idea seems like an outside stretch entirely to me because of the complexity of Magento and how it is overall setup.
But the idea is to remove/edit the Wordpress and FluxBB (and any other third party software) to pretty much ignore it's own method of registration, login, logout, edit and look to Magento for it's credentials and establishing new customers. Essentially making them an oversized module of Magento.
I just know that the way Magento is setup is to be modulerized and its complexity seems like it would take a lot more coding and troubleshooting to do this.
Brain Fart #3
Dump both Wordpress and FluxBB and look towards modules in the Magento Connection Store that pretty much has all of the functionality that I need and can add to them what is missing and not mess with trying to integrate third party software.
I love Wordpress, I think replicating it with a module, at least after the hours I have spent looking at all of the modules available that are CMS/News related is a tough call. FluxBB I could take it or leave it, if someone had an already viable solution to use phpBB or vBulletin or SimpleMachines I would go with them. I rather it be free open source software, not because I am a cheap skate but just because I support open source as much as I can.
Brain Fart #4
Can this be a cookie this, but would only be effective if they allow cookies, or could somehow addon to the session to allow things to pass through but Magento sets up different sessions or allows you too so they things to crash against each other so this may not at all be an idea or may be one as well.
I know I am not giving examples of things I have tried, files I have looked at or anything related to that and I apologize, I provide some links related but nothing specifically found so far that matches what I am trying to accomplish. And I have tried to merge things together with some fun disastrous results.
Link Examples?:
http://www.magentocommerce.com/wiki/doc/webservices-api/api/customer#customer.create
http://www.magentogarden.com/blog/how-are-passwords-encrypted-in-magento.html
http://www.nicksays.co.uk/magento_events_cheat_sheet/
http://www.magentocommerce.com/wiki/5_-_modules_and_development/customers_and_accounts/registration_fields
How to access Magento customer's session from outside Magento?
Any assistance with this would be nice, I am trying to work on several parts of the website at once and this one is troublesome and I would say that everyone is going to find it hard or have found it hard. Anyone like challenges? :)
--------- EDIT:
I have got Magento and Wordpress to work perfectly together with James Kemp's module found on CodeCanyon's website (Single Sign-On for Magento and Wordpress) and I am going to adapt it to work for FluxBB or anything else I do.
Just passing along the information... I see this was edited, don't know what was edited and don't care. Just passing along information I have since found since posting this.
I am managing/customizing a combo of magento+vanilla forums+a custom app made in Yii framework. The users are "shared" between the apps. None of the two links are good. As Alan already replied to you, the correct SSO will be with an external user database/manager. But well, not everyone is up to recoding three apps just to get 1 post a week forum and 1 article a month blog to work with magento. So we are left with less options. First of all, if you don't want (most probably not) to rewrite a good portion of already written open source project that is being updated and maintained and then maintain your changes against periodical updates (you want them), then you have to duplicate the user data over three databases. Unless the project you adapt has some way to manage users data as plugin or external module. AFAIK both of your choice don't.
So, how to implement it? Assuming you choose Magento as mother-of-all, you need it to export an API for authentication, which may work over browser using cookies and javascript but this is rather tricky, or you can use it's frontend cookie to validate the sessions doing server-server API requests from children apps. This is a preferred option as far as "classical" SSO goes. Technically, what should happen when your users open forum or blog, the respective apps detect magento's cookie and check if the session is valid and who is the user. If the user is found, his data is copied to the blog or forum tables. Then you need to start an authenticated session on blog or forum app using the newly created user record.
So far so good, but yet some work. you need to disable the user profiles management in the children apps or modify it so the data held in Magento is always the correct one and you need to invent something to synchronize the Magento's representation of user profile down to the children. This is better to be hooked up on Magento's events so every time a user changes his profile the data is updated in the children app. But there is another but too. You probably want to keep some data app specific, a display name on the forum is not necessary the FirstName+LastName from the Magento and some would like to keep it private.
The above is just what I can recall as interesting facts about keeping it running. There are certainly many other things I've left out, more or less specific. But hopefully my comment can help your brain farting.
We've tried to evaluate other options but anything without duplicate data seems to be too expensive to implement or to maintain. Maybe later. With budget and time.