Jiwa

Hi,

I am writing a plugin to stop any edits on a sales order if a delivery docket has been printed.

Originally the client had wanted me just to stop any printing if the delivery docket had already been printed, but now the spec is to stop all editing.
So far, the plugin code works nicely to stop printing. I also have a toolbar button to re-enable printing upon entry of a password.
The disabling/enabling printing code can be removed once I have code to disallow/allow editing.

I am having trouble finding the appropriate code to lock the sales order from editing. I did try SalesOrder.Client.Form.Enabled = False and although this worked it also locked the whole toolbar.

So I took a stab at using the abstract permissions and seeing if I can set it to Disallow. It seems to kinda work but when scrolling through the sales orders using the toolbar arrows, when I land on a sales order which shouldn't be locked it unlocks fine (sometimes - not sure why it doesn't unlock all the time) except for the History Status and Printed/Emailed indicators - these remain uneditable and the font colour is black instead of white.

Can you glance at my code and give me a better idea on the suggested way to prevent editing an order - and also the button I have to Enable Printing should have code to allow editing instead.

See line(s) 55, 56 etc on the attached plugin. And lines 70-76 for the button code.

Thanks

Danny

Danny,

I've found that the manipulation of the Edit abstract permission as you were doing should not be possible, as that property's setter is Protected Friend... ie: This

Code: Select all

SalesOrder.Client.EditPermission = JiwaApplication.Security.UserGroup.AccessLevels.Disallow

Should not work - but it somehow does . Given that is somehow magically does work (I'm yet to work out how), I found that I needed to also make the overloaded SetPermissions method of the sales order form public so that it could refresh the permissions on the form. SetPermissions is a method on the base Maintenance form class, which the sales order form inherits from. The sales order form overrides the SetPermissions method, to apply it's own flavour of permissions - but it overrides SetPermissions without explicitly being Public - so your plugin could not access it.

I modified the properties in Jiwa to be able to do what you need - but it's in build 7.00.136 - bug# 12024. Put simply, EditPermission needed to be made Publicly settable, and SetPermissions needed to be made Public.

With those changes in place, the form can then be manipulated like this:

Code: Select all

SalesOrderForm.EditPermission = JiwaApplication.Security.UserGroup.AccessLevels.Disallow
SalesOrderForm.SetPermissions()

With these changes, I was able to tweak your code and get it working. I didn't like you having a hard-coded password for the override of printing, so I incorporated aspects of the permission override sample plugin, so the user is asked to enter the username and password of a user with the abstract permission "Reprint Delivery Docket". The plugin has a SQL Script attachment to create the abstract permission.


This way, the users can be granted permission to edit a sales order which has a delivery docket printed by adding them to a group which has that permission. The customer can then maintain who is permitted to perform the actions themselves using the Jiwa staff configuration forms.

eg: Create a new user group, and add staff members to that group:


Then in the sales order entry form, give allow access to the group for the abstract permission:


From then onwards, the customer can add or remove staff members from the group, with no need to worry about modifying the plugin, and no concerns about what happens if a staff member leaves the organisation who knew your secret password or if someone accidentally discovered or learnt the password.

I also opted to prompt them for their credentials even if they had the permission, to prevent unauthorised passers by using an abandoned Jiwa session.

The modified plugin is attached


Remember - 7.00.136 is required for this to work. You may also want to alter the name of the abstract permission - it really should be "Edit sales order with printed delivery docket", as that better describes the function of the plugin now.

Wow, that's quite comprehensive!
I also was a tad apprehensive about a hard coded password but with time limitations and ignorance on a better method that seemed the fastest way to a workable solution.

When 7.0.136 is out I'll give your modded plugin a whirl.

Thanks

Mike,

I have finally have a chance to test this plug in.

A few problems.
1. Scrolling off a locked sales order, the next order is also still locked until I scroll again. EDIT: I've found that I need to click the Refresh to re-enable the form. Programatically adding in SalesOrderForm.RefreshRecord() just made Jiwa cry in a foetal-position screaming heap. Because it is in a ReadEnd event, the RefreshRecord executed the event again so was in a never ending loop.
So I added a RemoveHandler, then did the SalesOrderForm.RefreshRecord() then re-added the handler.

2. The status indicators (Printed, Emailed, history status) remain locked/disabled. I need them to be enabled again.

I have tweaked my plugin with some of your code. I still have the hardcoded password as it is just easier for the client & myself. I understand your reasoning though.
If you can assist to get those status indicators re-enabled, I'd really appreciate it.

Cheers

Danny

I have done some more work on this and have found the controls for the history status and printed/emailed indicators.
So when re-enabling editing, my code looks like this:

Code: Select all

      ' Force a refresh of the permissions
      _SalesOrderForm.SetPermissions()   
      'When on a previously locked sales order, and then you go to an unlocked order, the order needs to be refreshed to re-enable the fields.
      RemoveHandler _salesOrderForm.SalesOrder.ReadEnd, AddressOf SO_ReadEnd
      _SalesOrderForm.lblHistoryStatus.Enabled = True
      _SalesOrderForm.cmdNextHistoryStatus.Enabled = True
      _SalesOrderForm.cmdPreviousHistoryStatus.Enabled = True
      _SalesOrderForm.lblPrinted.Enabled = True
      _SalesOrderForm.lblEmailed.Enabled = True         
      _SalesOrderForm.RefreshRecord()
      AddHandler _salesOrderForm.SalesOrder.ReadEnd, AddressOf SO_ReadEnd


Now I have one last hurdle, when the sales order gets locked with the line

Code: Select all

_SalesOrderForm.EditPermission = JiwaApplication.Security.UserGroup.AccessLevels.Disallow

I would ideally still like the Printed and Emailed indicators to still be enabled so the user can click on them to see what has been done. I have tried enabling them just after the AccessLevels.Disallow line, but it seems the disallow is overriding the enabling.

Cheers

Danny

DannyC wrote:I would ideally still like the Printed and Emailed indicators to still be enabled so the user can click on them to see what has been done. I have tried enabling them just after the AccessLevels.Disallow line, but it seems the disallow is overriding the enabling.

As this is a generic issue - it has been logged as bug 12196.