Questions about user_sync

Florian

I think I did get user_sync to work, but I have a few questions about it.

1) Is there a way to trigger it somehow for all already existing users in the REI3 instance? Or how can I get all relevant users synced with a new app?

2) Is there a way to restrict sync to an app to users that are actually assigned a role for that app? It seems weird to have users synced into app contacts that are not permitted to use the app.

3) In the Organizations app, there is a user_sync function with the following lines:

	-- make sure that names are always set, use username as forename if not provided
	IF _user.name_fore = '' THEN _user.name_fore = _user.username; END IF;
	IF _user.name_sur  = '' THEN _user.name_sur  = _fallback_sur;  END IF;

Should the operators in the THEN parts not be := in order to assign values? And if not, why not? (I don't have any prior knowledge of PostgreSQL syntax, and pretty much only learn from your examples.)

As always: Thanks a lot for your help!

gabriel

Florian 1) Is there a way to trigger it somehow for all already existing users in the REI3 instance? Or how can I get all relevant users synced with a new app?

Yes. The function instance.user_sync_all() initiates the user sync for all current users. To execute this, you can create a backend function with a once schedule, which will run this function a single time, right after the app was installed or updated.

Florian 2) Is there a way to restrict sync to an app to users that are actually assigned a role for that app? It seems weird to have users synced into app contacts that are not permitted to use the app.

Sure - but, depending on the complexity of the app, it would often not be worth the effort. You would need to implement the logic in your user sync function to decide which users to sync and which to ignore. You can check for memberships (ie. relationships to groups/teams/etc. entities in your app), check for r3 role membership (via instance functions) and so on. And since things can change in your app, which would have an influence on your user sync, you would need to find all relevant events so you can trigger the user sync again, when needed.

Having a couple too many users in a relation is usually the much smaller issue than having users not being able to work because the app permission structure changed and the user sync was not triggered to include the user after the change.

Florian 3) In the Organizations app, there is a user_sync function with the following lines:

Well caught. Yes, the correct syntax is := for value assignment in Postgres PL/SQL. Using = also works and is probably supported because people are used to it. From the top of my head, I would guess that they chose := because it conflicts with how = is used in SQL as operator - and they wanted to separate it to make it clear when a value is assigned and when a comparison is done. Other languages often use == for comparison to make the difference clear - but SQL already uses = so I guess that is why they choose := for value assignment.

It is definitely best practive to use := afaik.

Florian

gabriel Yes. The function instance.user_sync_all() initiates the user sync for all current users. To execute this, you can create a backend function with a once schedule, which will run this function a single time, right after the app was installed or updated.

Is the application_id UUID as argument to instance.user_sync_all() required? If so, how can I get my app's UUID?

Florian

gabriel You would need to implement the logic in your user sync function to decide which users to sync and which to ignore. You can check for memberships (ie. relationships to groups/teams/etc. entities in your app), check for r3 role membership (via instance functions) and so on.

I had a go at this, and this is the relevant part of my user_sync function, with instance.has_role_any() having both roles in my app in its argument:

	IF _event = 'UPDATED' THEN
		IF (
			SELECT (kus_lab_db.contact.id)
			FROM {kus_lab_db}.[contact]
			WHERE (kus_lab_db.contact.user_id) = _user.id
		) IS NULL THEN
			IF (instance.has_role_any(_user.id,ARRAY['ab49f0d9-766a-41b3-b8d3-de2920ea607f','4607e6df-f270-4bc5-ad23-225fd9ea02a2']::UUID[],FALSE)) THEN
				INSERT INTO {kus_lab_db}.[contact] (
					(kus_lab_db.contact.user_id),
					(kus_lab_db.contact.name_fore),
					(kus_lab_db.contact.name_sur),
					(kus_lab_db.contact.email),
					(kus_lab_db.contact.school_id)
				) VALUES (
					_user.id,
					_user.name_fore,
					_user.name_sur,
					_user.email,
					_school_id
				);
			END IF;
		ELSE
			UPDATE {kus_lab_db}.[contact]
			SET
				(kus_lab_db.contact.name_fore) = _user.name_fore,
				(kus_lab_db.contact.name_sur)  = _user.name_sur,
				(kus_lab_db.contact.email)     = _user.email,
				(kus_lab_db.contact.school_id)    = _school_id
			WHERE (kus_lab_db.contact.user_id) = _user.id;
		END IF;
	END IF;

It seems to me that instance.has_role_any() does not read out whether a newly created or updated user WILL have that role, but only whether he ALREADY has had it prior to creation (impossible) oder update. Here is how I checked this:

Create new user without any role in my app. ➞ Contact does not get synced to the contact relation in my app. EXPECTED.
Add role in my app to that user and press Save. ➞ Contact does not get synced to the contact relation in my app. UNEXPECTED.
Make some other change to that user's settings. ➞ Contact gets synced to the contact relation in my app. EXPECTED.

Is there maybe a way to trigger the sync in step 2?

Florian

Thanks a lot for your quick and detailed answer, I much appreciate it.
(Same goes for all other discussion, too, of course. But I don't want to produce too much spam...)

gabriel

Florian
If it´s not defined as "optional" in the arguments, then yes it´s required. I´m currently traveling, so I cannot easily check - but I think it´s there to limit the potentially expensive initial sync to the app that needs it.

The app ID can be found in the Builder, if you go to "Application" in the left menu. Once in the application menu, you´ll find the show ID action on the top right.

Florian

Sorry to put you out! And sorry for asking an almost redundant question.

The help menu for user_sync_all actually states: "To work, a user sync backend function must be set in the application configuration page in the Builder; the required application ID can also be found there." (You could actually not have made it much simpler or more helpful...)

But I couldn't find the UUID. – Now I understand what these ID buttons are good for... 🙃

gabriel

Florian But I couldn't find the UUID. – Now I understand what these ID buttons are good for... 🙃

No worries, I am currently doing admin stuff on the train, so I am happy about the distraction 🙂

gabriel

Florian It seems to me that instance.has_role_any() does not read out whether a newly created or updated user WILL have that role, but only whether he ALREADY has had it prior to creation

Yes, this is correct. It will look at the current state and return the result accordingly.

Florian Is there maybe a way to trigger the sync in step 2?

Not at the moment. We´ve so far not considered the use case to choose whether to sync a user based on role membership, so we currently do not trigger a user sync on role change.

May I ask why it is important not to import user data for users that do not have particular roles? Is there a security issue or is it "just" for not creating unneeded records?

Florian

gabriel Not at the moment. We´ve so far not considered the use case to choose whether to sync a user based on role membership, so we currently do not trigger a user sync on role change.

I hope it's okay that I would slightly (and possibly wrongly) disagree. When I, as step 3, remove the user's role in my app, he gets synced to the app's contacts. My understanding is therefore that a role change does trigger a user_sync, but instance.has_role_any() reads out the OLD state instead of the NEW. – But this is only judging from my observations, and there might be something else going on under the hood.

gabriel May I ask why it is important not to import user data for users that do not have particular roles? Is there a security issue or is it "just" for not creating unneeded records?

I might be misusing REI3 a bit. Currently I work on three different apps for mostly separate but partially overlapping user groups. Since I read in one of your replies that one can also run several REI3 instances on the same server, I am mentally going back and forth between having all three apps in the same instance or in three separate ones. As far as I can tell, it would be easier to separate the three apps from one instance to three (by duplicating the initial one via backup/recovery and then deleting two apps in each instance, respectively) than starting with three instances and later on combine them in the same instance (because transferring an app with its data only works via a backup, and a recovery can only be done into an empty instance).

So as don't know yet where I will want to take things in the future, I thought I'd start with all three apps in the same instance, but kind of try to keep the apps as separate as possible. I suppose syncing all users to all apps wouldn't really be a problem as long as I don't expose the full contacts lists to regular users since a user that doesn't have access to an app can't create records in there, and hence should not occur anywhere.

Does my reasoning make sense? Or would you suggest doing things differently?

Btw. the forum software is excellent. The citing functionality is super useful...

gabriel

Florian I hope it's okay that I would slightly (and possibly wrongly) disagree. When I, as step 3, remove the user's role in my app, he gets synced to the app's contacts. My understanding is therefore that a role change does trigger a user_sync, but instance.has_role_any() reads out the OLD state instead of the NEW. – But this is only judging from my observations, and there might be something else going on under the hood.

Disagreement is not problem 😉

I checked the code and the user sync for updates triggers right after the meta data update, but before role changes are applied:

It might be a small change to execute the sync after the role change so that a "has-role" check via instance function would reflect the updated roles.

I´ll have a look at it.

Florian I might be misusing REI3 a bit. Currently I work on three different apps for mostly separate but partially overlapping user groups. Since I read in one of your replies that one can also run several REI3 instances on the same server, I am mentally going back and forth between having all three apps in the same instance or in three separate ones. As far as I can tell, it would be easier to separate the three apps from one instance to three (by duplicating the initial one via backup/recovery and then deleting two apps in each instance, respectively) than starting with three instances and later on combine them in the same instance (because transferring an app with its data only works via a backup, and a recovery can only be done into an empty instance).

There is definitely something odd in this scenario, but to get to the bottom of this would require a discussion and probably a whiteboard... 😅

In general, you should not need to backup / recover app data between instances unless you are restoring a production system or want to mirror something for testing. r3 apps are, in general, just meta data - empty shells that define how they work. They can include data (s. presets) for stuff like hardcoded states, workflows, example records and so on. But when data needs to be moved between r3 instances, you should look at APIs or CSV files. When you need to move (transfer) an app to another r3 instance, it´s like a fresh installation of a server application - without any data.

Regarding how apps are built and/or separated, this really depends on the architecture of what you are trying to build and what makes the most sense in your situation.

I generally try to keep entities together - for example, not having 4 relations if I need to store 4 types of people. Instead I would find conditions for separation and then filter accordingly (is it an employee, an external contact, superior of someone, etc.). This way changes/improvements to the entity (like display rules, processing) as well as features that work with this entity (like apps that deal with people) can work for all people records - instead of having to connect to multiple relations because employees and customer contacts are not on the same relation.

There are up- & downsides to any data structure and it might be more useful in your case, to split stuff up. But there are very few cases where outright duplication of entities is useful; and it comes with many drawbacks that can get costly when changes are required later.

Florian Btw. the forum software is excellent. The citing functionality is super useful...

Yep, we are still very happy with it ;)

gabriel

gabriel It might be a small change to execute the sync after the role change so that a "has-role" check via instance function would reflect the updated roles.

Good news: It was a small change to execute the user sync after role assignment. In r3.11.7 you will be able to use role checks reliably during user sync.