Sign in to follow this  
Followers 0

Move daily store management functions out of ACP

23 posts in this topic

Posted

I do not know if this is a problem that I only have...
I guess most of us will have small stores that are run by the same person that manages the board. But in certain cases (particularly with larger stores), it will be managed by other people. Not admins and board techies.

Therefore, I see a problem in having day-to-day store running functions, as part of the ACP. The ACP should be foreign territory for people into managing invoices and payments.
Even though it is possible to set ACP Restrictions for the "shop managers", there is still a lot of menus like System, Members, etc., that they will click on and result in [#1003] You do not have permission to access this page errors.

Why not move the Orders, Support Requests and Customers modules, to a "Manage Store" link or menu under the board Store page - and then only make this visible if the member has necessary permission? Or have a separate page altogether for the IP.Nexus ACP that doesn't have all the other ACP links and menus.

Alternatively, is the a way I can make a link to the IP.Nexus ACP that only shows that part?

Share this post


Link to post
Share on other sites

Posted

You really do want that sort of thing in the Admin CP ;)

ACP Restrictions are ideal for this sort of thing. You can't just make the Nexus section available, but improvements to the restrictions system to accommodate that is a good idea for IP.Board.

Share this post


Link to post
Share on other sites

Posted

[quote name='Mark' timestamp='1292181585' post='2054962']
You really do want that sort of thing in the Admin CP ;)


Thanks Mark. I can see that creating packages, managing payment gateways, etc., are functions for ACP.
But I cannot see why creating and invoice and dealing with a transaction is for ACP. Maybe you can clarify why you see it this way?

Share this post


Link to post
Share on other sites

Posted

Because it's a function to be utilised by the staff of the site rather than the members.

Share this post


Link to post
Share on other sites

Posted

[quote name='Mark' timestamp='1292182861' post='2054973']
Because it's a function to be utilised by the staff of the site rather than the members.


Agree that it is not for regular members. But just like certain Mod tools, the can also be handled outside ACP, provided one has the permissions to do so.
People managing shop sales are not necessarily site managers who know all the workings of ACP/Board.

Share this post


Link to post
Share on other sites

Posted

[quote name='Mark' timestamp='1292182861' post='2054973']
Because it's a function to be utilised by the staff of the site rather than the members.



Just to clarify, I am not talking about giving this to members - but to managers of the Store, who are not always site Admins.
I will add a little explanation below - and say that we agree to disagree on this one blushing.gif

I just spoke to a potential IPB forum customer and a little demo of IP.Nexus came to the same conclusion:

The Store is a good add-on feature to a board with a particular membership interest. Certain features of the store (membership renewals, etc) are geared for site admins adding revenue to their boards.
In most cases, this will be handled by the same person (Admin) dealing with all the daily management of the board. No problem - fantastic features.

But another and equally important feature of the Store, is the sale of physical goods (not at all related to the site admin features). And judging by the comments and requests for features here, then there is a great interest in using IP.Nexus for this too.
Take the example of a board specialising in vintage cars. They also selling odd parts and pieces for these. The IP.Nexus Store will be run by someone other than the site Admin. With the person I just spoke to, Invoicing, PayPal processes, Packaging / Shipping, etc., would be handled by a young girl that also takes care of their real world store. Expecting her to handle this daily things via ACP is asking too much, and therefore a lack of interest in using IP.Nexus.

I see the design mindset of IP.Nexus geared to ONLY cater for site admin people adding revenue to board admin functions, like membership renewals, group promotions, support requests, etc.

I can't see why you cannot separate these functions and cater for both "markets":

[*]Have the Admin in ACP maintain features like create new packages, groups, pricing, stock management, settings for payment gateways, etc.[*]Have a Store Manager page as a separate link in the store or added tab visible ONLY for users with the necessary IP.Nexus "manager" permissions, for the daily invoicing, transaction approval, payment submission, etc. ACP Restrictions just doesn't do this.
Otherwise great products from great people! Keep up the good work.

Share this post


Link to post
Share on other sites

Posted

[quote name='Mark' timestamp='1292181585' post='2054962']
You really do want that sort of thing in the Admin CP ;)
This has been one of my main objections with IP.Nexus. Please don't tell me what I want, I'm the customer, I'll tell you what I want.

Nick² likes this

Share this post


Link to post
Share on other sites

Posted

Sensitive functions of our software have always been in the AdminCP because if its inherit security. Functions like membership management, settings, forum control, etc. are all behind the AdminCP for a reason.

We consider most all the administrative functions of IP.Nexus to be sensitive and that's why they will stay in the AdminCP. I understand that it can be annoying having to go in the AdminCP but it's for the best in the end.

Share this post


Link to post
Share on other sites

Posted

I do get that there are reasons for certain things to be in the Admin CP, but I would much rather that be presented to me as the reason for why things are done the way they are, as opposed to being told what I want. Sorry, but that is a pet peeve of mine. As a customer, I should always be the one telling you what I want. I know that just because I want something doesn't mean I'm going to get it, but I still am permitted to want what I want, and not what you tell me I want. ;)

Share this post


Link to post
Share on other sites

Posted

[quote name='Michael' timestamp='1292254948' post='2055300']
I do get that there are reasons for certain things to be in the Admin CP, but I would much rather that be presented to me as the reason for why things are done the way they are, as opposed to being told what I want. Sorry, but that is a pet peeve of mine. As a customer, I should always be the one telling you what I want. I know that just because I want something doesn't mean I'm going to get it, but I still am permitted to want what I want, and not what you tell me I want. ;)


I'm sorry if my choice of wording hit a nerve.

I generally think it's better to reply with my thoughts rather than to remain silent in the feedback forum, and I hope disagreement is not being misunderstood as being dismissive.

Nick² likes this

Share this post


Link to post
Share on other sites

Posted

[quote name='Charles' timestamp='1292254741' post='2055299']
Sensitive functions of our software have always been in the AdminCP because if its inherit security. Functions like membership management, settings, forum control, etc. are all behind the AdminCP for a reason.

We consider most all the administrative functions of IP.Nexus to be sensitive and that's why they will stay in the AdminCP. I understand that it can be annoying having to go in the AdminCP but it's for the best in the end.



Again, I will disagree with which functions we term sensitive. Managing members, forum controls, etc - I think we all agree are sensitive.
But daily Mod functions are also not behind ACP for a reason.

Shipping, Checking payments, etc. are daily store "Mod functions". And If you do choose to place them in ACP, then I think I make a point in saying that they should be accessible as a totally separate page in ACP. I think IPS has to see products like IP.Nexus going beyond the scope of the traditional board forum functions.
I also consider it a security problem, that I have to start giving ACP access to more and more people, that deal with simple tasks like tracking orders, payments. etc. The more people in ACP, the less secure that gets, even with ACP restictions.

I have purchased IP.Nexus license and have not put it to any use yet - as I agree with Michael. This is restricting my ability to implement it.

Share this post


Link to post
Share on other sites

Posted

Surely the ability to approve payments is *the* most sensitive function any of our software handles?

Share this post


Link to post
Share on other sites

Posted

[quote name='Mark' timestamp='1292276722' post='2055429']
Surely the ability to approve payments is *the* most sensitive function any of our software handles?


Yes. But my question is: Is it a site admins reposiblity to do this approval?

In my company, I do technical stuff. Someone else does accounting stuff. Another does packaging & shipping.
Saying that I, the technical admin, has to also do the accounting and packaging and posting, because it is sensitive and has to be in the "holy" technical area is wrong.

Granted, I have to say who is Mod and has rights to approve these payments, etc. But they do not have to be forced to learn all the workings of ACP in order to be doing what they do with simple ease elsewhere.
My accountant handles accounts fairly easily in the company accounting packages, and I trust them to do so.

Give me the option to do the same here, without having to nearly make them site admins and have to deal with ACP.
And for sites where the Admin does all the above roles, no loss. He/she still can do this.

Share this post


Link to post
Share on other sites

Posted

[quote name='Charles' timestamp='1292254741' post='2055299']
Sensitive functions of our software have always been in the AdminCP because if its inherit security. Functions like membership management, settings, forum control, etc. are all behind the AdminCP for a reason.

We consider most all the administrative functions of IP.Nexus to be sensitive and that's why they will stay in the AdminCP. I understand that it can be annoying having to go in the AdminCP but it's for the best in the end.


There are a lot of functions which do indeed need to be in the ACP, like setting up the payment gateway and the like. However equally there are some functions which would benefit greatly from being both in the ACP and accessible from the frontend.

Support is a prime example that jumps to mind.

There are a number of sites run by modification authors who are currently using tera's ticket system to allow users submit requests for custom coded projects and give coders access to those requests. Those sites as it stands *must* run two separate ticket support systems because Nexus does not have a front end for tickets. It also means that users on those sites could very easily end up submitting duplicate tickets to each system, which is not a desirable situation to have. In fact some users may even submit sensitive support requests to the public ticketing system by accident and the site admin has no way to move it to the Nexus support area where it should have been in the first place.

Another situation where this setup would be useful is on forums attached to an online game. The admin may want his/her moderators to troubleshoot certain non-commerce related problems and then forward any requests needing admin attention to an "advanced support" department (for example if the site also sold merchandise associated with the game) which would have, and require, ACP protection. The admin would not, in general, want the moderators to have access to the ACP, otherwise they would have been made admins in the first place.

A more general example is a particularly busy and popular site that has support staff in the double digits. IP.Board has lots of nice protections to help admins secure their ACP from attack, however if the site wanted to move from their current support solution to Nexus as it's integrated with their forums and by extension other tools they have on their site. However they currently cannot do this because doing so would mean sharing the security details of the ACP with many many people and it only takes *one* employee leaving on bad terms or *one* of the many users who now have ACP access signing in from an insecure computer/location to potentially compromise many of the layers of security setup the ACP. To prevent this situation would mean adding extra administrative and security effort every time an employee leaves the company and restricting the ACP access to certain IP addresses (which is not always possible if the staff are working from places with dynamic IP addresses).

The solution to this, at least the one that jumped out at me first, is a relatively simple one. Allow the site admin to specify on a per "Support Department" basis whether or not it is accessible to specified groups from outside the ACP. The "frontend" interface should not display any of the customers "personal/sensitive data" as that data *does* need the protection provided by the ACP, but in general the contents of the support tickets would not.

I can absolutely see why you would not want customers private/sensitive data to be accessible from the frontend, and agree with it, however I don't see why that precludes having a frontend support interface that doesn't contain/display sensitive or private data. Just because it's used for one particular setup here does not mean that it couldn't or shouldn't be used for another equally legitimate setup elsewhere, however Nexus currently restricts the admin from choosing any setup that does not conform to the mdoel it's currently designed for. The way it's implemented at present is unduly restrictive imo.

[quote name='Mark' timestamp='1292276722' post='2055429']
Surely the ability to approve payments is *the* most sensitive function any of our software handles?


Sure approving payments may be *the* most sensitive function, but marking that an order has shipped does not necessarily need to be behind that many layers of security, nor does stock level adjustment or package creation/editing.

Nick² likes this

Share this post


Link to post
Share on other sites

Posted

I keep running into this problem. I have 3 potential forums for IP.Board/IP.Nexus that will not go this way, because of the ACP requirements for daily shop management. ermm.png

Most "one-man admin" forums, with a shop selling subscriptions and some digital products, will have no problems with the current design.

But for forums selling tangible products, where you have other staff doing invoicing, packing and shipping, then they do not want to be in the ACP.
They have nothing to do with the rest of forum and don't understand it - they just manage a physical shop (that happens to have a forum also).

So if you don't agree to move these things out of ACP, then please have a separate IP.Nexus ACP module, which can accessed separately to do simple things, that are not part of the complexity of managing the whole forum.

Share this post


Link to post
Share on other sites

Posted

I think the problem here is that there's a different mentality between forum "Admin CP" functionality and the control panels of any major eCommerce software. Over the years, forum admins have been told to keep Admin CP access minimal and only give it to certain people, etc.

However, there are a few things to consider here:

1. If you don't trust someone to access your Admin CP, should they really be dealing with payment information for you?

2. If you were using a dedicated eCommerce platform like Magento or Modernbill, you have no choice but to give your staff access to their control panels, there's no cross over between front end and control panel at all. Infact, they rarely even use the same user databases.

3. Wouldn't you want to protect customer information, payment information, etc. as much as you possibly can?

4. You can restrict access to the Admin CP down to the level where the only thing that an admin can view is the admin dashboard, and the IP.Nexus app.


Is it purely for convenience that people want all this functionality in the front end?

Share this post


Link to post
Share on other sites

Posted

[quote name='Dan' timestamp='1297766338' post='2080481']
Is it purely for convenience that people want all this functionality in the front end?

The people who work tickets on my site have nothing else to do in the Admin CP. When they come to my site to do their other duties, they have no means of even seeing if there are any tickets that even need looked at. This was such an issue on my site that I had to built my own public side access to the support system for my staff so they can do their ticket work and their other work without having to login to two separate things. So far, no disastrous breaches of security or member privacy have occurred as a result, and my staff is much happier.

Share this post


Link to post
Share on other sites

Posted

[quote name='Dan' timestamp='1297766338' post='2080481']
I think the problem here is that there's a different mentality between forum "Admin CP" functionality and the control panels of any major eCommerce software. Over the years, forum admins have been told to keep Admin CP access minimal and only give it to certain people, etc.

However, there are a few things to consider here:

1. If you don't trust someone to access your Admin CP, should they really be dealing with payment information for you?

2. If you were using a dedicated eCommerce platform like Magento or Modernbill, you have no choice but to give your staff access to their control panels, there's no cross over between front end and control panel at all. Infact, they rarely even use the same user databases.

3. Wouldn't you want to protect customer information, payment information, etc. as much as you possibly can?

4. You can restrict access to the Admin CP down to the level where the only thing that an admin can view is the admin dashboard, and the IP.Nexus app.


Is it purely for convenience that people want all this functionality in the front end?


I do agree that it is a mentality issue, and one that IPS are choosing to only see from one side. I still want to keep ACP access to a minimum.

1. The trust issue is not about what they are allowed to do. It is about what they should be doing daily.

To give you another picture: As the IT administrator in an organization, I am trusted to install and setup all the financial packages, e-banking systems, etc. But I am not trusted to be poking around them every day. I am the IT man, I don't do salaries or do banking. In much the same way, that a (trusted) person, handling the payments & orders in the shop, shouldn't be fiddling in screens with members setups, mod management, payment gateways and the sorts.

2. I am asking IPS to look at this from a client perspective dealing with real-life situations and consider this in your product development. Different packages from different developers work differently.

3. Again, the argument seems to be that I don't want to protect my customer information. I do and I will only give permission to someone I trust. I just want them to work in a separate screen/area from all the rest of the forum administration stuff.

4. Yes, I can restrict access and they will get errors when pressing restricted/forbidden links. Errors that are frustrating to have pop up occasionally. And something that makes the design of the package look messy.

I still argue, that there is no loss, to make a separate secure module like the ACP (lets call it SCP - shop control panel), where you can do daily shop management stuff. Same security, etc., as the ACP.
In ACP, you select which groups can use the SCP. So SCP has invoicing, payment processing, orders, stock, etc.
ACP has the payment gateways, package setups, etc. and even a link to SCP (so there is no loss for the "one admin" forum that always logs in to ACP - they can still access SCP via the ACP). cool.gif

Cheers

Share this post


Link to post
Share on other sites

Posted

Every ecommerce application out there keeps the staff functions separated from the customer functions for security and we will do the same. You can utilize the ACP restrictions feature in IPB to control overall access in your ACP. We are not going to expose any sensitive functions or information to the front-end and do not see the value in spending development time in creating a second control panel that does everything the ACP already does.

Share this post


Link to post
Share on other sites

Posted

[quote name='Charles' timestamp='1297783026' post='2080544']
Every ecommerce application out there keeps the staff functions separated from the customer functions for security and we will do the same. You can utilize the ACP restrictions feature in IPB to control overall access in your ACP. We are not going to expose any sensitive functions or information to the front-end and do not see the value in spending development time in creating a second control panel that does everything the ACP already does.


Agreed that staff functions and customer functions should be separate. I have never asked to put sensitive information on the front-end. I am pointing out, that there are now different staff roles. And very different to just admin vs moderator, etc.


How the design is made (second control panel vs a clean ACP page that only shows the "daily shop stuff") is something you know better that I do. I am just throwing ideas based on what I see is a need.

Example:
A large plant nursery has a shop selling plants. They have a forum community with this interest. Now they want to also sell stuff online.
There are a few shop attendants who they already trust in the physical shop, to make payments, do shipping, etc. These same people would be trusted to deal with the same things in IP.Nexus.
However, they are shop attendants and not forum admins - they shouldn't be able to change setups of IP.Nexus payment gateways, subscription packages, be this accidental or intentional.

So if you are running a site where there is the same role for Admin, shop manager, etc. - then no problems.
If you have various trusted staff doing different things, then they see a problem.

AlexJ and Painted Horse like this

Share this post


Link to post
Share on other sites

Posted

[quote name='Pfeiffer' timestamp='1297784268' post='2080548']
How the design is made (second control panel vs a clean ACP page that only shows the "daily shop stuff") is something you know better that I do. I am just throwing ideas based on what I see is a need.


I would rather look at expanding ACP restrictions in IP.Board to not show stuff you don't have access to.

Like Charles said, it is silly to creating a second control panel that does everything the ACP already does - that isn't to say though that there is not room for improving how the ACP presents itself to restricted users.

Share this post


Link to post
Share on other sites

Posted

[quote name='Mark' timestamp='1297784609' post='2080550']
I would rather look at expanding ACP restrictions in IP.Board to not show stuff you don't have access to.

Like Charles said, it is silly to creating a second control panel that does everything the ACP already does - that isn't to say though that there is not room for improving how the ACP presents itself to restricted users.


Agreed. Like I said, I am just throwing ideas and giving feedback - I never suggested a second control panel that does everything ACP does. If it does everything ACP does, then why have a new one?
I suggested something else, to separate the staff roles. However you achieve that is something you know better than I do.

Besides the improvement to ACP and how it shows itself to restricted users, there is still the part of restricting access with IP.Nexus functions itself.
Thus why I called this a SCP module (you can call it a separate menu in ACP) that doesn't have all the configuration stuff and just has daily store management.

Share this post


Link to post
Share on other sites

Posted

[quote name='Mark' timestamp='1297784609' post='2080550']
I would rather look at expanding ACP restrictions in IP.Board to not show stuff you don't have access to.

Like Charles said, it is silly to creating a second control panel that does everything the ACP already does - that isn't to say though that there is not room for improving how the ACP presents itself to restricted users.



I just gave this more thought.

If ACP restrictions work - like do not show the stuff users don't have access to - then effectively, you have created a 'second control panel' for IP.Nexus only - one that only deals with store stuff for users that I give these permissions/restrictions to.
So this would solve all the above.

But it has to work rolleyes.gif I don't even want the users to have dashboard access - and right now, when they login, they get an error on first page, before they even access the IP.Nexus App.

A suggestion to solve this, is also to add a little feature to the Manage ACP Restrictions setup for a group/user - Add a field where you can also enter link for the default "open container" for ACP login.
The admin can enter the startup place for the user logging into ACP. So if I have made ACP restrictions to only allow use of IP.Nexus, then I set the "opening container" field to be http://mysite.com/admin/index.php?adsess=9857012d7099857012d7099857012d709&app=nexus (or whatever it should be). shifty.gif

And I have said this a few times before - you guys make fantastic products. Please see all my comments, gripes and suggestions as an effort to bring positive feedback with the hope to improve on a already great suite of products.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Who's Browsing   0 members

    No registered users viewing this page.