Microsoft Dynamics AX Support

This blog contains posts by the Microsoft Dynamics AX Support teams Worldwide

AX for Retail 2012 R2: Password maintenance in the POS

AX for Retail 2012 R2: Password maintenance in the POS

Rate This
  • Comments 5

A new feature introduced in AX for Retail R2 CU7 is password maintenance in the POS.  This means that users can change their own password and store managers can reset passwords for staff in their store.  Here are a few tips to get started with this new feature.

First of all there is a minor issue that you need to take care of in AX before you can add the new operations to buttons in the screen layout.  If you go to your button grid layout designer and attempt to add either of these two operations to a button you will notice that the operations do not appear in the selection list.  This list is defined by the RETAILOPERATIONS table, which is normally populated during the Initialization process (Retail Parameters window).  However, the two new operations and permissions were left out of the seed data (we'll get that taken care of in a future release) so they need to be created manually.

To create the Permission IDs:

Open a new Developer Workspace and navigate to Data Dictionary > Tables > RetailPermissions.  Right-click on the table and select Open.  Create the two new records below. 

PermissionId = 1028, PermissionName = "AllowPasswordChange"

PermissionId = 1029, PermissionName = "AllowResetPassword"

Note:  the PermissionName must be spelled exactly as shown as it must match the column names in the RetailPosPermissionGroup table.

To create the Operations:

Open the Operations window (Retail > Setup > POS > Operations) and create two new records:  

Operation ID = 1215, Operation Name = "Change Password", Permission ID = 1028 (AllowPasswordChange), Check User Access = true, User Operation = true

Operation ID = 1216, Operation Name = "Reset Password", Permission ID = 1029 (AllowResetPassword), Check User Access = true, User Operation = true

2

To give users access to either of these two operations open the Permissions Groups window (Retail > Setup > POS > Permissions Groups) and mark either of the two new permissions for a permission group:

3

To add the operations to a button open the Button Grids window (Retail > Setup > POS > Button Grids) and open the Designer for one of your grids.  Right-click > Properties on any button and then open the Action drop-down.  You should now see your Change Password and Reset Password operations:

4

After creating the two new buttons push down all changes to the POS databases using either the N-1090 or A-1090 job (the subjobs for RetailPermissions and RetailOperations are included in these jobs) and either the N-1060 or A-1060 job (which includes the RetailPOSPermissionGroup table).

Once everything has been pushed to the POS you can now see the operations available to the user.  The two forms are pretty standard "change password" forms:

5  6

When the user changes either their own or someone else's password it will be changed in both the local database and in HQ (using the Real-time Service).  Passwords will not replicate to other stores until the either the N-1060 or A-1060 job is run for other stores.

In addition to letting users and store managers change passwords in the POS, an administrator in AX can force the user to change the password on their next login.  This is done by going to the worker form and marking the "user needs to change the password at next logon" checkbox:

8

After the N-1060 or A-1060 job as has run the user will get prompted the next time he or she logs into the POS:  
9

Some miscellaneous notes:  

  • The Change Password operation uses the standard POS security model; the user will be prompted for manager credentials if he or she does not have access.  However, in order to use the Reset Password operation the user has to have the permission explicitly granted.  Manager privileges are not sufficient.

  • If you are upgrading from a version previous to CU7, the new columns in the RetailPOSPermissionGroup table will be missing from subjobs and will not replicate.  This can be corrected by re-initializing the Retail seed data (Retail > Setup > Parameters > Retail Parameters > Initialize button) or by manually updating the Transfer Field List for the BDDP-RPPG and ADDP-RPPG subjobs.

  • Changing the password from the POS requires an active link to HQ via Real-time Service.  This is true even if you are not using local authentication ("Commerce Data Exchange: Real-time Service staff" is unchecked on the Real-time Service profile).

  • This new feature also includes the ability to define password strength requirements.  If you are using numeric PINs for authentication at the POS, this will mainly mean minimum password length, but you may also require uppercase letters, special characters, and numeric characters if you are allowing text passwords.  These settings are in the Retail Parameters window and are only enforced at the POS (temporary passwords set for new workers in AX do not follow these restrictions).

10

Hopefully you will find this a very useful new feature in the product – it should definitely be appreciated by AX administrators working with many workers across many stores!  Feel free to leave comments below if you have any questions.

Leave a Comment
  • Please add 3 and 7 and type the answer here:
  • Post
  • Hi Shane hope you are doing well. I am facing a issue that is to convert the internal POS transaction to retail transaction how to do this using the code.

    I would appreciate your help in this regards please.

  • Thanks Shane.  You always seem to have great explanations about really useful topics.

    I managed to add the Change Password operation button fairly easily with your clear instructions.  However adding a button for the Reset Password results in an error message, "This operation is not valid for this type of transaction."  

    So using BlankOperations, I tried:

                   ResetPasswordTransaction resetTrans = (ResetPasswordTransaction)posTransaction;

                   Application.RunOperation(PosisOperations.ResetPassword, resetTrans);

    but I get an exception message, "Unable to cast object of type 'LSRetailPosis.Transaction.InternalTransaction' to type 'LSRetailPosis.Transaction.ResetPasswordTransaction'."  Not sure what is preventing the casting from occurring.  Any ideas?

  • Hi Jeff,

    Usually when that message comes up it is because the operation is being attempted after some sort of retail transaction has already been started.  Can you try it immediately after finalizing or voiding a transaction?

    It doesn't surprise me that you cannot get it to work from the blank operation - I think you're running into the same problem - there is already a transaction "in progress" so it can't cast to the new type of transaction.  Trying to manipulate the transaction object in the blank operation is not always possible since it cannot return a new transaction.

  • Shane and I found a typo on the blog:

    PermissionId = 1028, PermissionName = "AllowPasswordChange"

    Should be:

    PermissionId = 1028, PermissionName = "AllowChangePassword"

    We also found the issue with the Reset Password generating the error:

    "This operation is not valid for this type of transaction."  

    The above error is generated when the Show Staff at Login is marked in the Functionality Profile.  As a work-around, if you unmark the box you will no longer receive the above error.

  • Shane and I found a typo with the blog.

    When adding the following to the RetailPermissions table adding the record below:

    PermissionId = 1028, PermissionName = "AllowPasswordChange"

    should be:

    PermissionId = 1028, PermissionName = "AllowChangePassword"

    Also, I did find a bug related to the error Jeff B is getting when selecting the Reset Password button:

    "This operation is not valid for this type of transaction."  

    The reason I received the error was because "Show staff at logon" was marked.

    The hotfix is in code review now, so look for a fix on Life Cycle Services soon.  The bug number is 1741722.

Page 1 of 1 (5 items)