onBeforeEdit or isEditable

[FriedDust]

Hello Eitan,
there are some cases where we cannot let the user edit or delete the
object.
for example, Invoice. once an Invoice is created, it should not be
edited or deleted.
I guess it would be nice if you could add a feature like isEditable()
and isDeletable(). the methods will return true by default.

public class AbstractComplexEObject
{
public boolean isEditable()
{
return true;
}
}

public class Invoice extends AbstractComplexEObject
{
@Override
public boolean isEditable()
{
return false;
}
}

thanks.
FriedDust

[Eitan Suez]

hi FriedDust,

  one way to control whether an object is editable by adding an authorization
  restriction on the command "Edit" (and "Delete") for a type.

  you can do this from the ui.
  you can also set this up programmatically.  if you subclass Application
  (and revise applicationContext.xml to specify your Application class
    as the bean with the id "application":

  <bean id="application" class="com.foo.MyApplication">
  )

  then you can provide an implementation for the method "initializePermissions"
  where you can do stuff like this:

      HBMPersistenceMechanism hbm = (HBMPersistenceMechanism) _pmech;
      Role defaultRole = (Role) hbm.fetch("from Role r where r.name = 'Default'");

      ComplexType customerType = ComplexType.forClass(Customer.class);
       defaultRole.addCmdRestriction(new CreationRestriction(customerType));
      defaultRole.addCmdRestriction().on(customerType.instanceCommand("Delete"));
      defaultRole.addFldRestriction().on(customerType.field("name"));
      defaultRole.addFldRestriction().on(customerType.field("phone"));
      defaultRole.addFldRestriction().on(customerType.field("address"));

  the default field restriction is a read only restriction (you can also set fields as hidden
  for a specific role).

  i hope this addresses your question.
  in the long term, i'd like to refactor AbstractComplexEObject to provide both
  a mutable and immutable versions that you can subclass from.

/ Eitan

[FriedDust]

hello Eitan,
I know we can hide the edit/delete button from the UI. but i'll give
you one example.
In accounting, we have Vouchers. if the voucher is Unfinalized then we
can let the user edit/delete it. but if the voucher is Approved by the
auditor then we may not let the user edit/delete the voucher. i dont
think this can be controlled by ManageRestriction in jmatter.

FriedDust

[Eitan Suez]

there's a way to do this.  i mean i recently ran across something
like this where i had a stateful object but didn't want to be able
to edit from that state.  i defined the states in which i didn't
want edit to be enabled by making it extend "State" instead of
extending "ReadState."  that removes a little too much though,
so i had to explicitly add back in the "Open" command.
here's an example state inner class:

    public class CompletedState extends State
155    {
156       @Cmd
157       public ComplexEObject Open(CommandInfo cmdInfo)
158       {
159          refresh();
160          return JobOrder.this;
161       }
    }

in your case the state name would be ApprovedState perhaps.

/ eitan