Osm Admin

Before diving into what should be in the docs, let's define what you should more or less know before using Osm Admin.

There are four types of people who will read the docs: power users, developers, vendors and contributors.

Here are my thoughts on product backlog and roadmap.

I waited for this day too long. Today, I've tried out GitPod, and made it work for a project based on Osm Admin.

Today, I reiterated on what's left in this iteration, and finished the side menu view, and created a trivial home page for the admin area.

After getting the main branch all-green (tests pass, CLI and UI works as expected), I decided that from now on, I'll keep it always green, and use feature branches for all major development.

Then, I started implementing the main menu of the admin area.

Yesterday, I created a template for new projects powered by Osm Admin.

This way, you can create and publish a project in minutes, just follow the README. Yay!

Yesterday, I tested the instructions for installing Osm Admin locally as a contributor.

Yesterday:

• Osm Admin in-browser functionality was fully restored after creating search index in the indexer.
• All test suites started passing again, and being run automatically on git push.

Yesterday started as usual, planning new iteration, and then BAM! - one folk - Saif - joined the project. It made me correct the course a bit, and take care of potential contributors:

• README explains what the project is about, and how to get started as a contributor;
• I'm fixing things to make the project actually runnable just after installing it.

Yay! After implementing invalid data conversion, I finished the iteration #18 dedicated to diff-based migrations!

I must say, it's a bit disturbing to implement the same thing for the third time. Still, the goal is to get it finished, and have it sustainable.

After the effort, the code has become su much easier to read!

I continued working on property diff algorithm that plans all the migration details.

Yesterday, I finished implementing data conversion for int and string property types.

Then, I started refactoring it.

Last time, I pushed through string property migrations and created a migration log.

Today, I continued solving data conversion issues.

• I finished implementing string property migrations.
• Migrations have got a meaningful log explaining what migrations take place, and why.
• Along the way, I fixed numerous issues.

Yesterday, I finished writing int property migrations. True, testing it is still a todo.

The major part of the code (type change, nullability and other attribute handling) will be reused in other property types.

I refactored Property::migrate() using additional Migration classes. It's so much more convenient to compare property definition versions and generate migration SQLs!

New code structure already handles property explicitness changes.

After enumerating what kind of changes can happen to a property, I started implementing the most hard one - changing property type.

The Query::bulkUpdate() method is implemented in the TDD way.

Recently, I implemented mass-editing in Osm Admin. It allows you to view and edit multiple objects in a single operation.

This article describes mass-editing of products in a typical e-commerce application.

In the user interface, you can narrow displayed data using grid column filters, or filters displayed in the sidebar. To enable that, apply #[Filter\*] attributes to class properties.

Applied filters appear in the URL query parameters, for example, .../edit?id=5+16+19, and on the page.

You can apply filters not only to a grid page, but also to a form page - to mass edit all matching objects, or to an action URL (edit, delete, or custom) - to perform the action on all matching objects.

In the same way, you can apply filters to the API URLs in order to retrieve or modify matching objects in a script.