I have installed and configured a Magento Community edition v1.8 according to a few requirements. Part of the requirements is the setup of a few stores.
For completion though, it is necessary to configure "administrators" per se for each of these stores. This administrator, when (s)he logs in to the admin portal, would be viewing data, configuration and settings only for their respective store, and the rest(of the stores) is not shown (As is the case when one configures an admin role via System -> Permissions -> Roles).
When the main administrator logs in to the back-end portal, they should view options for assigning these smaller (so to speak) administrators to their respective admin website sites. This list should be updated when stores are added/deleted (and hence the excellent Alan Storm's blog is not of much help)
I have been looking at various tutorials that enable and manipulate ACL, although none of them specifically tackle allowing such specific administrator access.
Can someone kindly point the right resources for achieving such a functionality? Any help is very much appreciated and will be rewarded with karma points :)
(I forgot to mention that I am not looking for a turnkey solution, but rather a direction to proceed, so that I may configure it myself. Any resource in this regard will be very helpful!)
Magento just doesn't work this way - it sounds like you are trying to create a kind of multi-vendor setup with each vendor having access just to their store/products. To achieve a robust, complete solution like this would require such widespread changes to standard functionality you would probably end up making it extremely difficult to upgrade the store, it would also take many, many hours of development time. Essentially, I wouldn't recommend going down this route.
Aitoc has made an extension for admin restrictions per strore. But Aitoc is not my favorite :). And than I'm kind in my words :) honestly we set them to our extension Blacklist
But if you want it : http://www.aitoc.com/en/magentomods_advanced_permissions.html
Note: on own risk ;)
Related
Is there a provision to use Google IoT core in multi-tenant way so that different user can use the same project but still only see their own device registries, devices etc?
An alternative way for you to solve your problem is to partition your users by project.
Particularly if the user is an organization|customer, this would provide you and the customer with the project's security boundary too. This would also give you partitioned registries and their devices.
A downside is in having to manage more projects but this is low effort.
Beyond perhaps the additional complexity, what would you not be able to achieve using multiple projects that you'd need?
As an addendum to DazWilkin's answer, if you DON'T partition your users by Project, then billing will all be put under one umbrella, which may not be something you want to do. You can't split billing within the same project to say "This registry get billed to this account, and that registry to that account". That may not be a requirement, but it's something to think about.
Why should I use AppHarbor addons when I can get an account directly from the provider and have additional benefits (like multiple users or projects per account)? I know having addons per application centralizes configuration but it also means you have to go through AppHarbor.
In addition AppHarbor adds their header on the website of some providers (notably Airbrake), which ruins the design (looks out of place and has massive margins). On some addons pricing is much more flexible than the addon pricing (again, Airbrake is a good example - no idea what those plans offer!).
Provisioning add-ons through AppHarbor gives you the advantages of automatic application configuration, consolidated billing and being able to manage everything from AppHarbor (and not having to remember X logins and not having to remember to keep X credit cards updated at various services providers).
We've tried to make make the header as inconspicuous as possible, and it seems to work well on most of our add-on partners sites. Please drop us a line at if it causes breakage anywhere.
We're also continuously working with our add-on partners to keep their add-on plan offerings up-to-date and I've just shot the AirBrake guys an email. Thanks for alerting us to the problem!
Say that I have two or more completely separate web applications. The might even be running on a different server and use different language & framework.
What I need to do is to share state, or at least authentication. For example if the user logs in on one of the websites and goes to another one, he will be able to authenticate using his credentials from the first website.
For example, if I have one website running e-commerce and another one is a blog, I want all the e-commerce users be able to comment on the blog with the information from their profile.
What is the best way to do this? Is it even a good idea?
The only solution that comes to my mind is abstracting away the profiles and authentication and create some kind of global profile and then use that on both of those websites. But that seems like a really complex solution considering what I need to achieve.
OpenID seems like a good way.
I've written an application and I'd like to add a registration key/serial number to it (I'm big on minimum inconvinience - ala #4 at this Eric Sink article). My question is about where to store the "activation" once the application has been registered. As I understand it, I have a trade-off between storing the key in a public place, where all users can read it (but which requires admin rights to save there) and storing a per-user activation (but then each user on the computer will have to activate independantly). That gives me two choices:
Some user, with local admin rights, activates the product. The activation is stored in HKLM, in the program files folder, or somewhere else where all users can read it, and the product is activated for all users.
A user (with or without admin rights) activates the product. The activation is stored somewhere user-centric (per-user app.config, HKCU, etc). The plus is that the user doesn't have to be an admin. The downside is that if there are 6 users who use the computer, each has to activate the product. They can each re-use the same serial, but they still have to enter it.
Is this really the trade-off? If it is, what have others done? As a developer, I'm used to people being a local admin, but in the real-world, I don't expect many of my corporate users to be local admins, which makes me lean towards option 2. Are computers not shared often enough that I shouldn't be concerned?
Again, I'm not asking about how to physically register a computer - I'm not worried about it. I'm only going to checksum the key provided and give the go-ahead, as I want to be as non-invasive as possible.
I would recommend a solution that does not require admin rights. Lots of users, especially in shared environments, won't have those rights and won't be able to find anyone with them conveniently.
Also, going forward a few years, I think it will be getting increasingly unusual to have admin rights on the computer you are using, as the security situation improves.
Registry seems to be an okay solution for business software. At least at where I used to work, regular user will not be a local computer administrator, so each installation will require local administrator account. This is a good thing since it will lessen the headache of your support staff from people installing just about everything in your business computing environment. The trade off is of course, user will be pissed that they can't install stuff or have to contact support to do it, but hey... :)
Other stuffs:
USB / other type of dongle (ala old
3DMax)
plain old text file (ala
Garmin GPS software on mobile device)
Encode them / rewrite the key into
your binary or part of your binary
(did this trick back in th old DOS
days)
Store them in your own db via web (ala EverQuest / other MMORPG games)
Local key db (ala MathLab I think)
How about using the isolated storrage for you application?
You will have the ability to store this information on a mashiene level for your registration, and the configuration changes can be persisted on a user level.
We save our activation code to the registry for the current user (HKCU) we have had very little problems with it. Our customers run on everything from home computers to thin clients on cooperate networks.
If your software will be used in schools or other educational environments you need to provide some other method. It could be as simple as a separate registration application which will save to the activation for all users. Your software would have to do two registry lookups but that is a small price to pay.
In general, most computers are used by a single user (or multiple people still using the same user account). So a user based storage will work most of the time anyway.
However it's not either/or. There are folder locations that are writable by all users - such as the ProgramData folder. The key is to make the file readable/writable by Everyone so that you can verify the content regardless of the user.
DeployLX Licensing does this for non-secure license data so that it can be used by multiple users without an admin explicitly granting permission.
You should be consistent. If administrator rights were required to install the program, it's not out of line to require administrator rights to register it. Likewise if you somehow managed to install it without administrator rights then register it without too.
If you install and register in one step this won't be an issue.
The company where I work for (1800+ Employees) is looking to enhance the personal relationships between its employees, allow a better collaboration and communication between departments and make it easier for the HR department to identify skills, experience and interests among the personnel (ex: we have some colleagues with deep knowledge of SAP modules and products, but during concrete projects it results very difficult to identify them and integrate them). Therefore, they want to implement a social network for our intranet.
We are just looking for the basic features such as profiles, discussion boards and so on, so nothing fancy. I proposed Community Server but my boss said .Net and java are no-gos. He wants LAMP and is not interested in a web solution like Ning, because of privacy and security concerns. It does not matter if it is Open-Source or commercial software. But it should allow a complete layout customization and must also have access from the outside world.
So my question would be, is there something like Community Server running on a LAMP stack?
Thank you very much!
UPDATE: We already have a Facebook page and a group. But my boss wants some features not included in Facebook such as a tag cloud in each profile page displaying skills and relevant proyects; and a feature like the "neighborhoods" from Last.FM, where you can group people with similar skills and interests and there is also the confidentialy issue (discussions about projects, clients, etc). So, any ideas?
You should check out StatusNet. http://status.net/
It doesn't directly answer your question, but aren't you rather trying to reinvent the wheel?
Facebook has got Social Networking down and the likely hood is 95% of your 1800 employees already use it.
Why would you go to the effort of writing and supporting a product as well as asking your employees to update information about themselves in multiple places when you could just set up a Facebook Network.
The other point I would make is, why are you limiting yourself to one way of doing things right from the off. Perhaps a detailed analysis of which technologies best serve your purpose would be more appropriate.
I appreciate this doesn't answer you question, I just feel this is a good example of Corporations unwilling to embrace tools already out there, I suspect because they are scared of them.
I'm probably right in guess that you're company heavily monitors Facebook usage, which is why this also might be hard.
Try Open Atrium, a Drupal-based team server.
Some sort of facebook application would allow you to keep the data on a server that you manage, but still use facebook's existing features. Pretty certain that facebook uses PHP for its application framework.
I agree with MrEdmundo and would upvote him if I were registered. Dont fall victim to "It wasnt invented here" syndrome. I bet your boss is like "we need something like facebook".
If it makes you feel better... here is a little story:
I was trying to implement some sort of group chat so fellow employees could ask quick questions to eachother online without having to get up or if someone was on the phone, etc. However, the service I installed (some sort of jabber daemon, i forget which one) never really got used. The solution? Just install the facebook chat client because all the co-workers are already on facebook most the day anyways!
plus, the "screen name" is appropriate because it is our real names, not stuff like "Out Into Space", "theman", or "fly-mystikal-dj-69"
You might want to consider something like Drupal. It's technically a CMS, but it's extremely customizable, and there are a lot of modules available that provide social-networking-style features.
Use Office Messenger for communication. It's basically like MSN Messenger but run on the company's servers so they can monitor all traffic. To know who has expertise in what area, it can't be too hard to build your own simple CRUD application to record profiles of employees and have each profile tagged with key skills, that the employee has and build a search function to find the people with the skills you need at any given time.
You can create an application using the Facebook SDK (PHP, java or any other language) and moderate it so that only employees can use it. That way you can use the existing Facebook features and add the tag clouds and other stuff your boss wants.
I've not used it, but Dolphin might be worth downloading to try out.
elgg.org
LAMP easy to install and setup, looks like your requirements would all be easily satisfied by the official plugins that are available.
Another option: http://buddypress.org/