Allow geofence property per project

[DrMurx]

It would be great to allow geofence properties per project. This may be most useful for the name property which could slightly differ in various projects, for usability purposes.

Example & Reasoning

For example, let's assume I have a geofence combining two close neighborhoods, named A / B in Koji. If I'd export this to Poracle which doesn't allow blanks, it will appear as A_/_B which is ugly to read and annoying to write for an !area command. So for this Poracle export, I may prefer A-B and I'd set the name property accordingly. On the other hand, I want the same geofence to appear as A / B on ReactMap, for better readability, but the name property is already occupied.

With a single name property, I have to chose. If I could specify the name property for each geofence per project, I have all the flexibility I need.

Design & Implementation

Option A

This option requires an additional nullable column project_id in the geofence_property table.

In the UI in the Geofence edit view, it needs an additional dropdown in the geofence's property list where the user would select a specific project (or no project in which case the property would behave as it is right now).

If users want to override a geofence property for a specific project, they can do so by editing a geofence, adding a property row, selecting the property key and the project, and enter the desired value.

Option B

This option requires an additional nullable column project_id in the property table.

In the UI, the Properties edit view would allow to select an optional project along with the mandatory name and category fields.

If users want to override a geofence property for a specific project, they first need to make sure that such a specialized property is defined in the Properties list. Then, they would edit a geofence, add a property row, select the property key for the specific project and enter the desired value.

Alternative proposal

As an alternative, Koji may just allow a property key mapping upon export.

This means a user would just define dedicated properties such as poracle_name or reactmap_name for their various geofences. The actual translation would be defined in the Projects edit view, ie. in the Poracle project the user defines a mapping of poracle_name to name, while in the ReactMap project, the user would define a mapping of reactmap_name to name.

[Fabio1988]

Why not using params? You can use replace for name props.. in your case you want to replace / with -

[TurtIeSocks]

Have you checked out the url param documentation? https://koji.vercel.app/api-reference/params they were added for exactly this.

[DrMurx]

@TurtIeSocks I'd argue that the params implementation is less flexible and less transparent as the results of the transformation are not immediately visible in the Koji UI.

[TurtIeSocks]

I'm not sure about less flexible since this allows you to customize it at the API calling level, compared to project wide.

And while I agree it's perhaps not the most transparent in the UI, this is why I made the /play page so you can experiment with it and see the results in a UI without having to make manual API calls to test.

[DrMurx]

Another point is that there might be a desire to transform names beyond trimming and replacement.

For example, one may decide to shorten certain common suffixes of cities, such as "Bakersfield" to "Bakersfd" or "Mexico City" to "Mexico C." (now I'm making stuff up, but I guess you get the idea).

[TurtIeSocks]

Honestly, I just don't want to touch anything related to names anymore. @Fabio1988 has had me run to the moon and back already, not to mention the queries involved with piecing together the table data into Features and the crud functionality for saving and associating properties are just too gnarly. Should they be made better? Yes, but I'm just not invested in them currently, as I think any non-made-up situations can be resolved with the right combinations of params.

[DrMurx]

I get your point, @TurtIeSocks . These things are quite difficult to handle.

But now that I'm thinking more about it, there may be a simple solution on the params level.

So instead of

pub struct ApiQueryArgs {
    ...
    /// If true, the `name` property is added
    pub name: Option<bool>,

we could do

pub struct ApiQueryArgs {
    ...
    /// If set, defines the name of the property which will be used as the `name`.
    /// If set to true, the `name` property will be used. If set to false, no name property will be included.
    pub name: Option<string>,