The extension is now able to add Taxon IDs and Comments as well
2 Likes
I am having trouble adding the extension to chrome (Windows). When I am going to Load unpacked, it says:
*The âbackground.scriptsâ key cannot be used with manifest_version 3. *
Use the âbackground.service_workerâ key instead.
Could not load manifest.
I am not too sure how to fix this - I tried changing the manifest.json from
},
âbackgroundâ: {
âservice_workerâ: âbackground.jsâ,
âscriptsâ: [âbackground.jsâ]
},
to
},
âbackgroundâ: {
âservice_workerâ: âservice_worker.jsâ,
âscriptsâ: [âbackground.jsâ]
},
but that did not work either. Any thoughts?
Hm itâs interesting that this is actually causing it to fail? In Edge it throws the error but loads anyway. My other tester has been using Chrome and hasnât had an issue. All you need to do is remove the scripts line though.
To be clear the reason both of these lines are present is because Firefox wants it as a script and Chrome/Edge want it as a service worker. In my testing both browsers throw errors about the one that doesnât match and then run with the one that does. When I ship the real versions Iâll remove the nonmatching ones but for building itâs easier to keep it all the same.
I got it working - thanks! Itâs already a huge help as it makes me actually want to annotate. Have you thought about adding the data-quality tab to it as well? I often want to click that the observation is not IDable any further, but donât because of the time/labor it takes for each individual observation. Either way, thanks for making this extension!
3 Likes
I was just gonna do another call for additional feature requests; I added everything that was requested so far this week but I knew I was still missing something. I will have the data quality stuff up sometime tomorrow.
3 Likes
Installed and running⌠phenomenal! Actually makes annotating fun 
. Can-t wait to see how it evolves.
5 Likes
Okay this is implemented now, if you just remove the extension and delete the folder and follow the installation instructions from scratch youâll have it. Donât forget to export any configurations you want to keep first though.
4 Likes
Great, thanks!
1 Like
Would it be a bad idea to be able to âmirrorâ the value of another observation field of the same type? If the person using the extension is adding a âNectar Plantâ obs field to an observation that already has âPlant the organism was found onâ, for example. They both have type of âtaxonâ, so it seems theoretically possible. But maybe a bad idea? And also maybe hard to do?
This is implemented.
Worth noting that the extension just does exactly what you tell it to do, so think carefully about how you implement these actions if you want to do more than one at a time. For instance, there are many fields used to record the host plant of a plant parasite. If you want to take Host, Host plant, Host plant species, Host plant identification, etc, and copy whichever one the user applied into Host Plant ID because thatâs the one your data structure uses, you can make an action that checks all of them at once (very convenient!). However, what it is actually doing is just copying each of them in order, and skipping the ones that are blank. In a case where multiple fields are already filled out, it will copy each into Host Plant ID sequentially. If theyâre all the same that doesnât matter; if some of them are different, youâll only end up copying whichever is the last action in your configuration.
Also note that this of course overwrites any existing value in your target field.
Whatâs the current official download link, still the one in the OP?
1 Like
Thatâs awesome!
1 Like
Yes, that link pulls the most recent version from GitHub so it should stay up to date as I continue developing.
1 Like
Great, thanks!
only export configurations that are âenabledâ? I may only want to share some of my configurations. scared of editing json!
If the tool allows two redundant observation fields to become 1:1, it might make sense to add functionality to âlockâ one of the redundant observation fields so it canât be added to new observations. Once any projects using the locked field switch over, the locked observation field could be deleted. It seems like sometimes even the âownerâ of the obs field might be open to dropping it but canât control which projects and users have come to rely on it.
itâs difficult to normalize user defined meta data without offending some of the users who defined it. it seems like getting them to 1:1 and then locking one might be reasonable. it would give time for there to be push-back and inquiry while itâs locked.
if the tool is used for large scale setting of observation fields to ultimately clear redundancy, hopefully the âmuteâ functionality blocks notification of an observation field being added. I think maybe it does.
1 Like
I sympathize with this impulse but all of that is outside of my control and I would be surprised if the iNat admins went for it
1 Like
It does.
1 Like
Wow! Thanks for all of the time youâve put into this extension! Iâm excited to use it!
Any chance you can make a short video tutorial?
2 Likes
