Authenticated CRUD

Continuing the discussion from Extension of development deadline:

Today this continues and concludes with the intermediary delivery of a work in progress to demonstrate the integration of authenticated CRUD.

It is based on the milestones M1 and M2 from the collaboration agreement.

What becomes apparent when looking at this, is the missing issue definitions for Anonymous View / Create and Authentication alike. This made the authorization question primary target for implementation of M1 and M2.

After reviewing the high-level concepts in the documentation, understanding the basic components of a Rails application, depicting the 18 primary models used, and testing of the MVC CRUD patterns, different forms of specification of intent where found througout the source code. This renders the implementation strategy from following a linear-hierarchic, top-down model, as such implementing feature branches against specific issues, into a diagonal-transversal, inside-out model, in which cross-references appear and an ‘ecologic’ style of development emerges.

Parallely we have a specification growing to be more explicit, not only in the written documentation, but also from reviewing, implementing and interacting with the application mechanics.

From the code review, more questions appear to be worth asking:

  1. How are composed models expected to be handled via the HTTP JSON API?
    • resource_address
    • resource_collection
    • resource_email
    • resource_link
    • resource_phone
    • resource_section
    • resources_sections
    • user_email
  2. How are links to be introduced between the high-level models? Some are provided upon creation through providing a foreign key. How do we add or change links between existing resources?
  3. How do we expect resources to be addressed? Some resources are defined to be addressable via a UUID, while others aren’t. ( Which is the distinction line that we can draw between both? Do we want to address all publicly accessible resources with UUIDs instead?

Technical details live in the associated merge request, where more in-depth information is present.

I think the day day of the extended deadline for delivery is really to late to do a code review and ask preliminary questions, those should have been asked early november.

heum… no this jargon does not make any sense.

Thank you @yala for asking. I’m disappointed you do so after your self-imposed deadline since it concerns the fundamentals of the software.

resource_* are relations attached to one or more resources. They are to be used as glue from their relations’ entrypoints (e.g., attaching an address to an entity creates a resource_address). In the first phase, where we only worked with imported data sets, these were handled programmatically from Rails relationships chains through their parent models, since we were importing flat data into this more complex model system.
resources_sections and user_email are joint tables used internally by Rails.

One should be able to POST or PATCH the resource endpoint with includes set to the model you want to attach to the resource. The exposed model in the JSONAPI is composite, but its representation is flattened with the includes statement that enables fetching relations. Then the create or update controller action can handle the case of attaching high-level models together. E.g., you could attach an address to an entity by PATCHing the entity with a new relationship with the address, given you know the address ID.
The proper way to do this would be to add the missing controllers for each relation to be handled this way – see below.

Records with UUIDs are supposed to be read using their UUID. They are searchable, but otherwise UUID is the main entry, hence a map can deploy to a list of UUIDs that can be fetched independently.
Records without a UUID are “secondary” records that are composed within records with UUIDs. For reading purposes – i.e., public use – only records with UUIDs (high-level models) should be considered. But for the system to acquire all its functionality, other controllers are of course required (which were not necessary in the first phase) and constitute part of the job to implement M1 and M2.

Since this was not obvious to you, and you didn’t ask, it was not obvious to me why you would not do it.

I guess I’ll have to go through your MRs (which I already did mostly) and cherry-pick what’s useful (e.g., bug squashing changes). I intend to make some basic posters to introduce the various ideas behind IN COMMON code so anyone can have an overview without sticking to what they see from a previous stage, which unfortunately does not seem to communicate much about the actual intents.

As @natacha suggested, we should find you another task within the project so that you can eventually come back later to the code when it is sufficiently advanced for you to grasp without losing yourself into insignificant details and missing the big picture. I’m sorry this didn’t work out so well. We were desperate to find someone to pursue the task of implementing the code and trusted you from your continuous engagement with the geo-commons scene. But we totally missed the communication layer. That such questions pop up now and not last November are a terrible reminder of our collective failure to address simple basics. I wish you had come to OFFDEM and spent some time together so that such question bubbles would have popped much faster.

Yeah, that was the case: except you didn’t see the bud and considered a sick plant. :slight_smile:

Hi @how, after continuing with the merge reqest from your comments, which helped me to clarify some concepts, I can see that there are some implicitly present that come from the Ruby on Rails application, and others that were implemented to meet the idea of the IN COMMON API. Sometimes it was not clear for me to understand which concepts derive from which perspective, and why some would be very specific implementations that try not to generalise.

It appears fair to me that the resources are in charge of their relationships, and that we do not need to mutate these compound models manually. What we need to make sure though is, that we can access these relationships and eventually mutate or destroy them, when needed.

There are nice ways of using UUIDs as primary keys for all models with Rails 6. What is it that motivates this hierarchy of different means of addressing and levelling for you? To the outside user, all routes appear on the same level, and the qualitative distinction may appear arbitrary.

Given the two quotes from above, I hope you are witnessing the same contradiction as I do. Where the specification of the development to be done came with many implicit assumptions and tasks, the reverse engineering and explication of the steps needed is the actual task of diving into significant details which make up the greater whole.

Because the task of writing other controllers is of course required does not mean it takes part in a structured development process where functional requirements (of the users) and technical requirements (for the developers) are evaluated and put into context, in so details and bigger picture are at balance.

This is probably were we both could have put more effort into, to distinguish the experiences and expectations with which we enter into the collaboration, before starting right away. Secondly I deem personal interaction quite substantial, where textual, asynchronous collaboration can become very dry and unpersonal.

Also last November we were occupied with getting the development engine to run at all, and didn’t spend time to investigate the code base together. Of course you can take for granted what you wrote and built for yourself, as a third party these observations may not be available to me. Why I am happy that is now here with us, and we can extend from there.

A little process methodology may be better than no process at all.

In advent of OFFDEM end of January, I had talked to you and @fodevaux bout the possibility, and both you and @natacha, but also him, suggested to me that there would not be much time to talk about IN COMMON that weekend. This is why we had decided to push a personal meeting into a time frame where we all would be much less occupied.

Would you still think it’s a good idea to meet for once in person, after all?

Could be, but we’re far away from each other. It could take some time to converge.

@yala can we find a moment to talk and review the next steps? I don’t have a phone nor permanent connection now, but we can find a way :slight_smile:

Yes, please! As soon as possible can be better for me.

Maybe tomorrow or on monday?