Directory file management in merged server projects

Projects introduced the new directory.json file containing users, groups and permissions. It allows authentication, restrictions, permissions on several parts of the application, through settings or code. Let’s see the new improvements about this file usage in merged server projects.


On a project, the users, groups and some permissions are saved in the directory file. To remind yourself of how it works, you can read this presentation blog-post again or watch this video.

Directory files

The project directory file is the directory.json file located in the project user settings folder (Settings folder next to the Project folder of the project in use):

The data directory file is the directory.json file located in the user settings folder for data (Settings folder next to the data file in use):

The application directory file is the directory.json file located in the application user settings folder (Settings folder inside the Server Database folder of the merged server application):


Embed the file during build application process

So far, it was your job to include a directory file in the merged server after build application process. If you don’t include a directory file in the application package or next to the data file, during the execution, all the users are using the Designer account with all its rights.
So to make it safer and easier, from v19R5, a new buildApp key is at your disposal. This key automatically embeds the project directory file in the merged server during the build application process:


Note that this new setting is also available in the Build Application dialog:


Server-side behavior

The current behavior is maintained: the 4D Server loads the data directory file if it exists. Otherwise, the application directory file is loaded.
But from now, in a merged server project, all modifications made to users, groups and permissions during execution are automatically stored in the data directory file. The application directory file is never touched and can be considered as an initialization directory file. This will guarantee your application signature stays safe on macOS, or allow you to place your server application in a read-only folder without any error.
At server startup, if no data directory file exists, the users, groups and permissions stored in the application directory file, if they exist, are loaded. Then, if modifications are performed on users, groups or permissions, they are stored in the data directory file.

Technical accounts

Users and groups are often used as technical accounts by 4D developers. This can be done using the toolbox, or with 4D code by testing the current user name with Current user or the group membership with User in group. In such cases, to make sure these users and groups are persistent, you can check them at server startup, and subsequent modifications will automatically be stored in the data directory file!

• Product Owner •Damien Fuzeau has joined the 4D Product team in February 2019. As a Product Owner, he is in charge of writing user stories, then translating them to functional specifications. His job also entails making sure that the feature implementations delivered are meeting the customer needs.Damien is graduated from the University of Nantes in software engineering. He spent more than 23 years in its former company, first as developer (discovering 4D in 1997), and later as engineering manager and software architect. This company is a 4D OEM partner and deployed 4D based business softwares for thousands users, on hundreds servers. So, Damien is used to 4D development and deployment in a multi-language context.