logo
Welcome to our new AbleCommerce forums. As a guest, you may view the information here. To post to this forum, you must have a registered account with us, either as a new user evaluating AbleCommerce or an existing user of the application. For all questions related to the older version of Gold and earlier, please go to AbleCommerce Gold forum. Please use your AbleCommerce username and password to Login. New Registrations are disabled.

Notification

Icon
Error

Options
Go to last post Go to first unread
jeffr_ca  
#1 Posted : Wednesday, May 12, 2021 11:49:03 AM(UTC)
jeffr_ca

Rank: Advanced Member

Groups: Authorized User, Developers, Registered, HelpDesk
Joined: 1/7/2019(UTC)
Posts: 112

Thanks: 1 times
Was thanked: 2 time(s) in 2 post(s)
Hi All,

Is it possible to have all users automatically be added to a group as soon as they register an account? Joe had made mention of a _default_ group, but I don't see this in any Group drop-downs.

The purpose would be to have registered users see a discounted price on the product page or at least have the discount automatically applied in the cart during checkout?

Thanks!

-Jeff

Wanna join the discussion?! Login to your AbleCommerce Forums forum account. New Registrations are disabled.

shaharyar  
#2 Posted : Monday, May 17, 2021 5:47:08 AM(UTC)
shaharyar

Rank: Advanced Member

Groups: Admin, Developers, Registered, HelpDesk, Authorized User
Joined: 10/5/2018(UTC)
Posts: 703

Thanks: 5 times
Was thanked: 113 time(s) in 112 post(s)
In AC9, we have removed the ability to assign/unassign the default group.

To achieve the requirement, you can enable the feature by commenting out a code block in the js file.

1- Open the file \Website\Areas\Admin\Scripts\custom\app.js
2- Search and comment on the following lines of code.

Code:
// HIDE THE "_Default_" GROUP FROM AVAILABLE SELECTIONS
    $('.chosen-select').chosen().on('chosen:showing_dropdown', function (e) {
          var chosenElement = $(e.currentTarget.nextSibling);
          chosenElement.find('li.active-result:contains(_Default_)').remove();
    });

    $('.chosen-select > option').each(function () {
        if ($(this).text() == "_Default_") {
            $(this).remove();
        }
    });
jeffr_ca  
#3 Posted : Tuesday, May 18, 2021 12:25:17 PM(UTC)
jeffr_ca

Rank: Advanced Member

Groups: Authorized User, Developers, Registered, HelpDesk
Joined: 1/7/2019(UTC)
Posts: 112

Thanks: 1 times
Was thanked: 2 time(s) in 2 post(s)
Thank you.

Is there some reason why the functionality was removed? A performance or other admin/system issue?

-Jeff
shaharyar  
#4 Posted : Wednesday, May 19, 2021 2:28:41 AM(UTC)
shaharyar

Rank: Advanced Member

Groups: Admin, Developers, Registered, HelpDesk, Authorized User
Joined: 10/5/2018(UTC)
Posts: 703

Thanks: 5 times
Was thanked: 113 time(s) in 112 post(s)
There was a discussion about this feature and we decided to hide this group based on some reasons.

- This was done to avoid the situation where a merchant can get confused.

e.g A merchant uses member groups and also has normal registered users. There is a discount of 20% set up for the member group. There is a second 10% discount set up for the normal registered customers. The user who belongs to the member group will get both discounts, instead of just the 20%.

- Another reason was that this group is sort of a special system group and should not be treated as a normal group.
Joe Payne2  
#5 Posted : Wednesday, May 19, 2021 7:42:49 AM(UTC)
Joe Payne2

Rank: Advanced Member

Groups: HelpDesk, Developers
Joined: 11/9/2018(UTC)
Posts: 564

Thanks: 122 times
Was thanked: 26 time(s) in 25 post(s)
The problem isn't multiple groups get a discount. The problem is the discount system does not have a priority feature. Create the ability to establish discount priority and add a global toggle for 'apply best discount only' or 'apply all discounts'.
Joe Payne2  
#6 Posted : Monday, May 24, 2021 7:46:16 AM(UTC)
Joe Payne2

Rank: Advanced Member

Groups: HelpDesk, Developers
Joined: 11/9/2018(UTC)
Posts: 564

Thanks: 122 times
Was thanked: 26 time(s) in 25 post(s)
I've encountered another issue with your decision to exclude _DEFAULT_ as a group choice.

In Able Gold, volume discounts permitted the selection of _DEFAULT_ as a group. But in Able v9, the group is not rendered.

You can't just hide it. Upgraded installs have it persisted in the data. So now I have a volume discount that WILL apply to a specific group but I cannot see that group has been assigned in the UI.

Edited by user Monday, May 24, 2021 7:57:24 AM(UTC)  | Reason: Not specified

charles25686713  
#7 Posted : Wednesday, March 6, 2024 2:39:41 PM(UTC)
charles25686713

Rank: Advanced Member

Groups: Authorized User, Developers
Joined: 7/1/2022(UTC)
Posts: 64

Thanks: 5 times
Was thanked: 1 time(s) in 1 post(s)
I'm resurrecting this 3 year old topic...!

There are legit business reasons to have all users automatically added to a user group.

It appears this _Default_ group is still used, as all our users are in it.

The above mentioned fix to remove the hiding of _Default_ seems to still work.

Please consider bringing _Default_ officially back, and/or consider changing
Code:
NewUserAccountCreated
in
Code:
DefaultEventsHandler
to be overrideable to give customers the flexibility of adding this functionality on their own.

Thanks,
Charles

Edited by user Wednesday, March 6, 2024 2:41:09 PM(UTC)  | Reason: Not specified

charles25686713  
#8 Posted : Wednesday, March 6, 2024 3:50:39 PM(UTC)
charles25686713

Rank: Advanced Member

Groups: Authorized User, Developers
Joined: 7/1/2022(UTC)
Posts: 64

Thanks: 5 times
Was thanked: 1 time(s) in 1 post(s)
I just learned how to add a handler to NewUserRegistered. This is different from the old way of overriding the function, but it works just as well.

It appears the code on this page http://api.ablecommerce.com/topic23689.html referring to how to add handlers to events is obsolete/incomplete?

Code:
var eventHandler = new MyEventsHandler();
             EventsManager.Instance.OrderPlaced += new OrderPlacedHandler(eventHandler.OrderPlaced);
             EventsManager.Instance.OrderCancelled += new OrderCancelledHandler(eventHandler.OrderCancelled);


But it got me in the right direction and I was able to add a handler in Global.asax.cs that hooks into my code.

Edited by user Wednesday, March 6, 2024 3:51:37 PM(UTC)  | Reason: Not specified

Katie S  
#9 Posted : Thursday, March 7, 2024 12:27:44 PM(UTC)
Katie S

Rank: Advanced Member

Groups: System, Administrators, Developers, Registered, HelpDesk
Joined: 10/29/2018(UTC)
Posts: 423

Thanks: 4 times
Was thanked: 34 time(s) in 33 post(s)
Our team had in-depth discussions about the _Default group during AC9 development. I don't have time today to get into all the details, but I'm happy to provide our internal discussions upon request.

The main point is that the _default group was used to distinguish between anonymous and registered users. In Gold, there was confusion because the group was accessible in the UI and people would remove it, but our maintenance scripts would add it back again.

The _default group assignment is not the same as normal group membership.  By showing it to the merchants, we are confusing them.  It is not a group assignment that should or can be removed from the User record.

I tested in Gold and AC9.

In Gold, we show the _default group separate of other groups (implying that it cannot be changed).  The UI allows it to be removed, but doesn't actually update and save the record.

In AC9, we also allow the group to be removed, but the record is never saved. (before issue AC9-361 was implemented)

The purpose of the _default group is simply to let us know if the account is valid (Authorized User) or anonymous (account disabled).


These Improvements were suggested at the same time, but it was never implemented because of the impact to the application at the time of release.


The classification of users -

1. All
2. All Registered
3. Grouped (the ones that have some merchant defined group assigned)
4. Ungrouped (the ones that do not have any group assigned)
5. Anonymous
 
With default we have been trying to represent #4. i.e; Ungrouped. Unregistered is equal to #5 i.e; Anonymous.
 
Now read the concluding comment as follows:

The code confirms that with _default we have been trying to implement 'Ungrouped' users.
What happens is that we enforce the 'Ungrouped' group to all users that have no group assigned. We do not automatically reassign _default group to users who have any other merchant defined group assigned. So if the merchant manually removes the _default group it will not be reassigned to the user as long as there is some other group assigned to it.
 
However this implementation has one flaw. If we were trying to represent 'Ungrouped' users we should have them automatically removed from the 'Ungrouped' group as soon as they were added to any other merchant defined group. Since we do not do this removal it is possible for a user to be in _default group as well as some other group. Which is not valid since _default is trying to represent only the 'Ungrouped' users.
So what we need to do is to

  • Update the code and ensure that users are in Ungrouped (_default) group only when they do not have any other group assigned. If they get assigned to any other group the Ungrouped group should be unassigned for them.
  • We should also rename the _default group to 'Ungrouped '.
  • Assignment and unassignment to 'Ungrouped' should happen automatically. It can not be changed by the merchant.
  • Merchant can assign different features like discounts and coupons to the Ungrouped group.

 
Implementation note : 'Ungrouped' is a special group. It is a predefined group that will be part of the default installation script. Special groups need to be given special treatment. There can be other special groups as well. (I have mentioned the possible classification above). For now we will have just one special group 'Ungrouped'.
We need to implement it such that we do not have to hard-code for each special group. We need to do something like this.
  • Add a new boolean field to Group. "SystemGroup".
  • "Ungrouped" will be a "SystemGroup"
  • If a group is "SystemGroup" it can not be edited in the merchant admin. Merchant can not add/edit it and its members.
  • When assigning features, system groups are available. For example discount assignment and etc.


In addition, with respect to the store access restrictions feature - no changes will be required. The following will work as before.

  • None = No restrictions
  • RegisteredUsersOnly = All registered users have access. Anonymous users are denied access
  • AuthorizedGroupsOnly = Only users from authorized groups have access.
  • Admin users will always have access



Quote:
In Able Gold, volume discounts permitted the selection of _DEFAULT_ as a group. But in Able v9, the group is not rendered.


Now lets come to the problem above. The merchant wants to achieve something that is currently not supported as is. The merchant does not want to define a discount for 'any' registered users but wants to define discount for all non-group users. This is actually a new requirement that we currently do not support.


Quote:
It appears the code on this page http://api.ablecommerce.com/topic23689.html referring to how to add handlers to events is obsolete/incomplete?


Yes, unfortunately, the api site is getting outdated. Once we release the next version, I'll see if we can allocate some resources to getting this updated.

Thanks for your support!

Katie
Secure eCommerce Software and Hosting
charles25686713  
#10 Posted : Thursday, March 7, 2024 5:33:11 PM(UTC)
charles25686713

Rank: Advanced Member

Groups: Authorized User, Developers
Joined: 7/1/2022(UTC)
Posts: 64

Thanks: 5 times
Was thanked: 1 time(s) in 1 post(s)
Thanks for the feedback.

We're good to go with leveraging the NewUserRegistered event, and it doesn't depend on the quasistability of _Default_.
Users browsing this topic
Guest (2)
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.