radiant-maxar / maprules-ui Goto Github PK

when trying to build, not grabbing the urls from the this object caused this problem

ERROR in src/app/modules/attribution/start-maprule.component.ts(39,39): error TS2304: Cannot find name 'idUrl'.
src/app/modules/attribution/start-maprule.component.ts(40,41): error TS2304: Cannot find name 'josmUrl'.
src/app/modules/attribution/start-maprule.component.ts(49,34): error TS2304: Cannot find name 'osm'.

the initial attempt to make requests to tag info based on other combobox values was...bad. that's on me!

Instead, how about every time a dropdown is open in a tag-combobox, we build an HTTP request, subscribe to it, and update the dataList with its response. with cached requests this should be fine (not firing off a bunch of duplicate requests). Also, I think we do not ignore keys in other forms from dropdowns consistently. let's do that too!

Suggest tags used by the the locale of Area of Interest

I noticed that when I

1. saved a new config
2. clicked edit mode to update it
3. clicked save again, it created new hash/url

appears the code was always doing a 'post' like it was a new config on save.

this ticket tracks work to manage the 'put' for updating configs.

Add list of existing MapRules in Explore section
Show options to "View", "Edit", and "Use Preset in Editor" on each MapRule

what's a site without that awesome branding?

also ensure that only one value can be selected when a numeric value condition is selected

to keep a history of previous revisions to maprule

I noticed that sometimes that the dropdown would be in an 'open state' even after selecting values.
After investigating I think I just need to make a few changes to the click handling in the combobox component

looks like GitHub flagged some vulnerable packages, will try to handle this

We love tests! Let's make sure to add some tests! Particularly for the services class, but also for the components...should be a good way to tech up on how the ins and outs of angular

When versioning is implemented, allow users to visit previous revisions and revert the rule
radiant-maxar/maprules#48

So that a MapRule can be edited/built upon without affecting the original MapRule it was derived from

show the selectize inputs before taginfo finishes loading

Allow users to specify grouping for presets

Allow value from list of values to be selected as the default value. The preset should still show other values as options that can be selected, but will have the default value selected.

Allow users to specify relations and associated features

Switch tab rules icon to maprules logo

make the UI more condensed

previous issues like #37 and work for #44 has illustrated the "selectize" has led to some problematic logic and gotten in the way of some of the dynamic capabilities w/angular forms.

this ticket tracks removing "selectize" and relying on some custom code for things like...

1. filtering options based on user input
2. matching fieldConfig schemas w/ the form builder schema

ex: https://wiki.openstreetmap.org/wiki/Item:Q574#P13

This ticket is to begin the conversation about how instructions may differ for a beginner and a more advanced mapper.

on config submit, the app should redirect to /:id/start to show instructions. we can do this by just executing location.go(${above.location})

In the event that users may want to share or import or modify presets and validation rules (locally)

branch #7 ended up also having lots of ui changes.
this ticket finishes that...

Make sure form validation appears under inputs upon submission

Add install instructions and description on how to integrate into other applications

To reproduce:

1. Add 3 disabled features
2. Remove the 2nd feature added
3. Add another disabled feature (key and value)
4. Try to change the 3rd disabled feature's key and it updating the wrong selectize

Allow users to save MapRules to their account and decide whether to make them public

With login work coming along in #65 it's time to get going on the front end implementation.

Reading some material like this article and this github thread, and also following the hot tasking manager's network requests when it does its login, I have a flow (which I own, and hope isn't a total Frankenstein).

What I think we need is this:

1. A user opens up the MapRules UI and we initially check to see if their current JWT is valid with a request to our api's /auth/session route
2. If we get a 401 we go ahead and request the /auth/login route, which returns a url for logging in with OSM, we open this page in a new window.
3. A user goes about logging into osm which makes a call to our /auth/callback route
4. This /auth/callback sends a 302/307 redirect to a new /authorized route, which includes an HTTPONLY session cookie and a query param.
5. The browser redirects to authorized route, which the ui will handle by making a new req to /auth/token(including that http session token. This, if successful, returns the JWT needed for all future requests to resources.

Being that the functionality of the Combobox (having a dropdown of options that can be selected and be set as an input's value) is separate from other code we have to get suggestions for dropdowns from tag info, we should separate these functionalities.

A parent Combobox that handles the former, and a child, that we can call 'tag.combobox' can do the later.