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.
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.