I've just set this up for myself and my misses. However, I've noted that you can't seem to set up geofences for shared sessions.
This would be useful as sometime she has to go out with little warning, and I don't know if she has without looking it up. We also happen to live in different countries, so keeping track of each other can be a little fun >.<
Can this be added for shared sessions please? Possibly even with an option to turn the feature on/off for the shared link? Annnnd maybe be able to have geofencing post normal notifications?
Before thinking about implementing something new, here are the available solutions for you :
the other person can log to a session that you own, then you'll be able to define a geofencing zone for his/her device. Side effect : the other person won't be able to define a geofencing zone for his/her device as he/she does not own the session...
you can choose the destination email when you define a geofencing zone. the other person can set a geofencing zone which sends you an email.
By "normal notifications" I mean the notification system Nextcloud natively has. These happen to get pushed to the desktop and android clients quite nicely.
With the other solutions though:
the other person can log to a session that you own, then you'll be able to define a geofencing zone for his/her device. Side effect : the other person won't be able to define a geofencing zone for his/her device as he/she does not own the session...
I'd like to try and avoid that side effect. It is her phone, I don't want to make her feel like I'm taking control of this, as she won't have access to my accounts.
you can choose the destination email when you define a geofencing zone. the other person can set a geofencing zone which sends you an email.
I did notice this, but I'd like to try and use the notification system. It also relies on her having to set it all up.
I guess I've ended up asking for two features here.
For a push notification option (where email notifications are offered), that uses Nextcloud's notification system to inform users,
To be able to use shared point data in ways we can do with our own data. It's already been shared with us, so this just expands what we can do with the shared data. This would only make sense when it's shared with another Nextcloud user though.
Hey how, early Christmas. NC notifications are available for geofences and proximity alerts. It's been pushed to master branch.
@Valdnet and @Ryonez (and anybody else ), i'm interested in your feedbacks.
I discovered that google services are required in the Android client to get push notifications... Grumf.
Now that PhoneTrack notification system is implemented, i'll add notifications for events like "add user share", "user quota reached"... Thanks again for this suggestion.
About 2., i've been thinking... Here is a public memo :
Let's take the geofence example.
a geofence is defined with a device id
a device is defined with a session id
when a session is shared, an entry in oc_phonetrack_shares is inserted. Such entry contains a session id and a user name
Let's say user "A" shares session "S" to user "B". Then let's say "B" wants to add a geofencing zone for a device "D" of session "S".
From there i can think about 3 options to make 2. happen :
the simple one : "B" is authorized to add a geofence "G" for devices of session "S" like if he/she was the session owner. The zone will be visible by user "A". Notifications will be sent to users "A" and "B". "A" will be able to delete "G" even if he/she's not the one who created it. "B" will be able to delete any geofencing zone created by "A" (the session owner). Problems : "A" might not want to see "B"'s geofences. "A" might want to protect his/her geofences from potential deletion from "B". Good aspects : The database structure is not modified. It does not break anything.
the intermediate : we add a field named "readonly" in oc_phonetrack_shares. If the share is NOT readonly, "B" can add/delete geofences (like in 1.) for any device in session "S". Good aspects : It gives more control to user "A". It does not break old user shares (defined before the database modification). Default "readonly" value for existing user shares could be false. Problems : "B" might not want "A" to see the geofences he/she creates. We have to notify A and B for a geofence
the complex/dirty/satisfying one : we find a modification to geofence definition to make it possible to isolate geofencing zones created by "A" and by "B". For example, geofences could be defined with a device id AND a user name. Each user will only see the zones he/she created. Little problem : if "D" is moved to another session which is not shared with "B", we have to delete the geofences created by "B". Big problem : This looks like spaghetti code. Good aspects : This modification does not break old geofences. An empty user name in the geofence entry could mean "the session owner". Each user just sees his/her geofences. Same for notifications.
In my opinion, I would not introduce this option. If the owner of the session is the user "A", then only he can decide who to notify, share the session, etc.
My idea is this: to add a function of selecting which user "B", "D" we want to notify via NC when creating geofencing.
I sadly don't use geofences currently, I have my device on me at all times.
In my opinion, I would not introduce this option. If the owner of the session is the user "A", then only he can decide who to notify, share the session, etc.
My idea is this: to add a function of selecting which user "B", "D" we want to notify via NC when creating geofencing.
My view on this, they've already shared the point data. We have that, we could already do anything with that
My main concern with this idea though is I'd have to teach them all about the geofences. An option to enable it for shared users can make geofences could work. But keep in mind, they could do it anyway if they really put some effort into it.
Option two could work better here maybe. It'd eliminate the need to teach the user, while having them keep control. The issue is the notifications at that point. Maybe a workaround to that would be to create notification "steams".
For this, there'd be a a, b, and c notification "steam". When working with options such as geofencing, you can have one output to steam "a". Then, under the share with user menu, one could "subscribe" to notification steam a. Then, when anything is sent to that steam, users subscribed would get that notification.
We could also have a custom "steam", lets call it d. When d is enabled, the subbed users will get an email of that notification, via their nextcloud email. Atm, you can only set a single email, so this could make it more versatile.
So with all of that, you introduce the following oc_phonetrack_shares database entry.
'readonly`: Whether the user the session has been shared with can edit it. Populate with true on initial field creation. Catches old entries, and is a secure default for new ones.
To oc_phonetrack_geofences:
notificationsteama, notificationsteamb, notificationsteamc, notificationsteamd: These would be the steams to send notifications to, boolean value.
emailaddr, set this up so the code can handle comma separated values. This just expands the options you could do with this when manually adding emails.
To oc_phonetrack_proxims:
notificationsteama, notificationsteamb, notificationsteamc, notificationsteamd: These would be the steams to send notifications to, boolean value.
emailaddr, set this up so the code can handle comma separated values. This just expands the options you could do with this when manually adding emails.
Then the GUI needs to be adjusted as well, for geofences and device proximity.
The only thing I haven't accounted for is where to put the owner's stream subscriptions. Maybe a new notification section should be added, to just deal with it all there. Next to the session share option maybe.
I really wish I had my server stuff sorted, I would've looked into maybe even trying to help with a pr.
Weird, wasn't notified of that. The update came through the app section just before, so updated there.
Works out for me, I don't really want to worry about git repo's for apps within docker. I'd give myself a headache >.<