Custom User Object

Sometimes, using the default User object is enough for an app, but most of the time a custom User object is needed, which has specialized fields and does not necessarily need most of the fields existant on User (address, phone number etc etc).

In order to use a custom user object, it is necessary to create an inheritor of the platform SimpleUser object. Create an object, like you would to normally, but then specify the following :

  • Extend of Code: SimpleUSer
  • Table: m_user
  • Tray Menu: no
  • add a “type” enum attribute (you can do that via using the template editor, as you’d do normally)

Then, we add the following code to the object, to make the object really minimalistic, by hiding most of SimpleUser’s fields, and automating group attribution:

package com.simplicite.objects.Demo;

import java.util.*;
import com.simplicite.util.*;
import com.simplicite.util.tools.*;

/**
 * Business object DemoUser
 */
public class DemoUser extends com.simplicite.objects.System.SimpleUser {
	private static final long serialVersionUID = 1L;
	
	@Override
	public void postLoad() {
		super.postLoad();
		// hide most of the SimpleUser fields, keeping only email & login
		getField("usr_first_name").setVisible(ObjectField.VIS_HIDDEN);
		getField("usr_last_name").setVisible(ObjectField.VIS_HIDDEN);
		getField("usr_image_id").setVisible(ObjectField.VIS_HIDDEN);
		//getField("usr_email").setVisible(ObjectField.VIS_HIDDEN);
		getField("usr_lang").setVisible(ObjectField.VIS_HIDDEN);
		getField("usr_cell_num").setVisible(ObjectField.VIS_HIDDEN);
		getField("usr_active").setVisible(ObjectField.VIS_HIDDEN);
		getField("usr_home_id").setVisible(ObjectField.VIS_HIDDEN);
		getField("row_module_id").setVisible(ObjectField.VIS_HIDDEN);
		
		// hide all users that were not created throught this object
		setDefaultSearchSpec("demo_user_type is not null");
	}
	
	@Override
	public List<String> preValidate() {
		// set some mandatory SimpleUser fields
		setFieldValue("row_module_id", ModuleDB.getModuleId("ApplicationUsers"));
		//following does not work because usr_menu is not part of SimpleUser
		// we manage it in a postSave query to avoid adding a useless object attribute
		//setFieldValue("usr_menu", "1");
		setFieldValue("usr_active", Grant.USER_ACTIVE);
		
		return super.preValidate();
	}
	
	@Override
	public String postSave() {
		List<String> groups = new ArrayList();
		switch(getFieldValue("demoUserType")){
			case "ADMIN":		groups.add("DEMO_ADMIN"); break;
			case "USER":		groups.add("DEMO_USER"); break;
		}
		setRespList(getRowId(),groups);
		
		// meh practice... query instead of adding usr_menu attribute to objet
		getGrant().update("update m_user set usr_menu='1' where row_id="+getRowId());
		return super.postSave();
	}
	
	private static void setRespList(String userId, List<String> newGroupsList){
		List<String> oldGroupsList = getRespList(userId);
		// remove old unused groups
		for(String oldGroup : oldGroupsList)
			if(!newGroupsList.contains(oldGroup))
				Grant.removeResponsibility(userId, oldGroup);
		// add new missing groups
		for(String newGroup : newGroupsList)
			if(!oldGroupsList.contains(newGroup))
				Grant.addResponsibility(userId, newGroup, Tool.getCurrentDate(), null, true, "ApplicationUsers");
	}
	
	private static List<String> getRespList(String userId){
		if(Tool.isEmpty(userId))
			return null;
		Grant g = Grant.getSystemAdmin();
		String[] groups = g.queryFirstColumn("select distinct g.grp_name from m_resp r inner join m_group as g on r.rsp_group_id=g.row_id where r.rsp_login_id="+userId);
		return groups!=null && groups.length>0 ? Arrays.asList(groups) : new ArrayList<String>();
	}
}
2 Likes

L’enregistrement m’indique que je ne respecte pas la syntaxe. Est-ce un problème?

Bonjour Ophélie,

Non ce n’est pas un problème, effectivement dans le cas des héritages la syntaxe n’est pas respectée.

1 Like

Erreur de compilation de notre côté :’(
on a enregistré une première fois sans adapter à notre objet (qui ne s’appelle pas DemoUser). Est-ce l’origine du problème ? Il ne semble pas prendre en compte notre modif

Bonjour Simon,

Y’a-t-il un moyen de virer le filtrage dans le menu ?
image

Merci d’avance.

Il est possible de ne pas afficher le sous menu des états d’un objet à état par

@Override
public void postLoad() {
  (...)
  setMenuStates(false);
  (...)
}

Dans l’onglet Options de l’objet métier :

image

J’avais bien décoché ces options, sans succès.

Mais en utilisant :

setMenuStates(false);

Ca fonctionne. Merci beaucoup.

Oui cette méthode d’affichage/masquage du sous menu n’a, pour le moment, pas encore été câblé sur un flag paramétrable. Ce sera sans doute le cas dans une version ultérieure.

1 Like

Effectivement, j’avais mal compris le besoin.

En fait pour les accès par état, cela se paramètre au niveau du state-modèle = on peut dire si on veut qu’un état soit dans le menu ou pas (il peut y avoir des états transitoires ou finaux non pertinents pour un accès direct).

Pour un objet User qui hérite du socle, mieux vaut passer par du code dans l’hériter.

1 Like