Arches 5.1.0 released

[Cyrus Hiatt]

The Arches team is happy to announce the 5.1.0 release which includes a number of important new features and bug fixes:

Here some of the release highlights:

• Bidirectional support for the resource relationship datatype. Resource relationships saved to a tile are now represented in the search page's related resources interface.
• Users are now able to restrict access of an instance to specific users and groups.
  
• The date datatype, widget, and advanced search now support time.
• Tile edits and deletion made on the web are now synced with instances in a collector project.
• Arches now provides an annotation datatype and interface allowing users to annotate imagery from a IIIF service.
• Improved management of front-end dependencies so that Arches upgrades are less likely to impact project customizations.
• Improved support for localization. Administrators can now configure their Arches interface to switch between different languages.
• You can find the detailed release notes here: 5.1.0 release notes

Users are encouraged to update at their earliest convenience. If you are upgrading from Arches 4, be sure to follow the project upgrade instructions to 5.0 before proceeding.

As always the documentation can be found at <http://arches.readthedocs.io>

[Adam Cox]

Nice work all! The upgrade steps look good and thorough :)

We'll have a big update to the documentation very soon, so stay tuned. I think we should also make sure to set up clear links to these release notes.

Adam

[OsTechMan - អស់តិចមែន]

Hi Everyone,

Yes, I would like to second Mr. Cox and congratulate the Arches Project team and community to just put out another sprint release of the wonderful and growing Arches ecosystem!

Thanks very much for the great work!

Best regards,

Woody Chao at Ostechman Systems

in...@ostechman.com

P.S. Personally, I came from Cambodia which is a place once hosted an instance of human civilization in Southeast Asia. I am not an antiquarian or archaeologist but drawn to this area because literally cultural artifacts are still incidentally appearing and discovered by villagers and farmers almost on a daily basis, tl say nothing about the ones littering around on the Earth surface  areas in the country. I happened to start working in IT after schooling in sociology. So, these days I am spending some time with CRM materials and maintaining an installation of Arches for such a personal study of the tools and technologies invovled CHM. https://arc.kumroo.com.

--
-- To post, send email to arches...@googlegroups.com. To unsubscribe, send email to archesprojec...@googlegroups.com. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en
---
You received this message because you are subscribed to the Google Groups "Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to archesprojec...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/archesproject/fbc451c9-24df-463e-a312-be1bb2ddd534n%40googlegroups.com.

[Markus S.]

Hi all,

Congrats and thank you for a new version! We just performed an upgrade from v5 to v5.1 to give it a whirl. It's now working fine, and we are excited to see the new features (including language switcher!), but we had the following issue during installation:

The new or upgraded JS dependencies were missing from the /media folder after the upgrade. We had performed the package.json change as per the instructions and had run 'yarn install' after deleting the yarn.lock file. The assumption was that this was going to take care of the JS dependencies, downloading and placing them in the appropriate directories. However, when loading the Arches' Search page, the web browser was complaining about missing JS files - the very ones that were updated or new. We resorted to downloading the missing JS files and placing them in the appropriate directories manually, which fixed the issue.

What should we have done differently? This was on a Windows server.

Markus

[Cyrus Hiatt]

Thanks Markus,

I'm glad you got things working. I'm not sure what went wrong with your JS dependency installation. Can you confirm that you ran `yarn install` from the directory with your package.json file rather than the one with manage.py? You probably did it correctly, but running yarn from the manage.py directory is an easy mistake to make..

Thanks,

Cyrus

You received this message because you are subscribed to a topic in the Google Groups "Arches Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/archesproject/R2fFULsuSgs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to archesprojec...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/archesproject/975404be-9e6c-4068-889d-a67b62bbf742n%40googlegroups.com.

--

Cyrus Hiatt
Geospatial Web Developer
Farallon Geographics
601 Montgomery St, Suite 1095
San Francisco, CA 94111
Office: 415.227.1140
Cell: 831.295.2439

[Markus S.]

Cyrus,

Thank you for the reply. I did not do the upgrade myself, but I will check with the person who performed it. My assumption was that it was done as you described but it would not be the first time we made a mistake! I will report back here once I have an answer.

Markus

[Phil Weir]

Hello all,

We did the 5.1 upgrade on Wed/Thu and, while it was generally smooth, hit a couple of bumps - although we had the same demo on master from a couple months back, so somewhere in between 5.0 and 5.1.

Our flow is a bit different because this deploy is Kubernetes/docker based, but we did find that the new project package.json seemed to just pull in the archesproject/arches#5.0.0 package without its dependencies. I had assumed this was down to the approach we were using, but might be related? Our workaround was to use the package.json in the root directory, and that solved our issue for the moment (specifically, d3 expected to be under a dist folder in the new version, and giving a 404).

As a side-node, we came across one or two other upgrade issues - in particular, reindexing ES threw an exception (concept relation not found in concept_types.py:68) - again, I'd put this down to how we had done the upgrade so didn't want to add noise, but if it'd be useful to file a more detailed report, can do.

All the best and thanks for all the hard work on the new release!

Phil

To view this discussion on the web visit https://groups.google.com/d/msgid/archesproject/fb2fca22-9563-42df-bd97-88d41b131c41n%40googlegroups.com.

[christop...@historicengland.org.uk]

Congrats on the 5.1.0 release! We're not quite in the position to adopt it during the Warden system update deployment already in progress, but certainly for our other projects we'll be looking to adopt it ASAP.

In any case, there are some very useful features there, so thanks for your work.

Best wishes,

Chris Dolby

Project Manager

Historic England

[Markus S.]

This suggestion turned out to be correct. Thank you!

On Thursday, October 29, 2020 at 3:47:09 PM UTC-7 Cyrus Hiatt wrote:

[kuba...@gmail.com]

Hi,

I also upgraded to version 5.1.0 - I have only small trouble with elastic search reindexing.

{'type': 'illegal_argument_exception', 'reason': 'mapper [tiles.data.3a9f46c0-f538-11ea-ac6d-9fb7e90de197.features.geometry.coordinates] cannot be changed from type [long] to [float]'}
Using: 
python manage.py es index_database 
instead of:
python manage.py es reindex_database 

did the job so I propose to change that in upgrade instruction:

https://github.com/archesproject/arches/blob/stable/5.1.x/releases/5.1.0.md

 

Best regards! 

[Alexei Peters]

Hi kubalobo@gmail,

It looks like the error message you received is because you have geometric coordinates that are integers mixed with coordinates that are decimals.  Elasticsearch (ES) dynamically maps incoming fields based on the first document indexed.  It appears that the first document had integer based coordinates and then in a subsequent document decimal based coordinates were being saved.  ES will complain about this.  I would try and fix your geo data such that all coordinates are floats.  

The reason `python manage.py es index_database` worked is because the mappings were preserved by that command and what was stored in ES were evidently correct, but this was not the case when the mappings were remade during the "reindex_database" command.

I hope that explains the issue somewhat.
Cheers,
Alexei

Director of Web Development - Farallon Geographics, Inc. - 971.227.3173

To view this discussion on the web visit https://groups.google.com/d/msgid/archesproject/dae9f0f0-40cf-400a-8b1c-961b6887c65cn%40googlegroups.com.