ksobon / MagnetarCA

MIT License
0 stars 1 forks source link

Self Describing Attributes #1

Open gschleusner1972 opened 4 years ago

gschleusner1972 commented 4 years ago

If you think about these files as transactions you need more data then just the details on each element to ensure that they can act alone without other details being included. IE. If I send you one of these files via email would it have enough information so that you would not have to intervene to ensure it goes to the right location? With that in mind, we'd need to add the following to the RFI, Response data and then Add the ProjectUUID to the project. Also I think we need to create a json descriptor of the attachements tht have a matching name with this same info.

ProjectUUID ParentUUID - (for Responses to RFIs and future item types) PredisesorUUID - (This is used for responses. The responses should be ordered so a second response's "PredisesorUUID" would be the "ItemUUID" of the first responce, , where the ParentUUID for the second responce is the "ITtemUUID" of the RFI itself.

ItemUUID - All elements would have this. UTC Timestamp ItemType (RFI,RFIComment,RFIAttachment)

{ "Number": "002", "Contractor": { "Name": "Konrad's Contracting" }, "ContractorRfiNumber": "005", "Subject": "Just testing another", "ReceivedDate": "2020-09-21T15:21:38.1960914Z", "DueDate": "2020-09-28T15:21:38.1960914Z", "Details": "This concept would work well for a host of design related data types. Issues. Schedule. Even a slow chat app.", "Attachments": [] }

ksobon commented 4 years ago

@gschleusner1972 well, I guess the big picture question here is this: Do we have a requirement for each object to be fully self describing? The reason I am asking is before, we didn't have that requirement. As a matter of fact, I think it was opposite. We talked about specifically not putting additional information into these individual RFI files, because their location would give us context. Literally their location on a hard drive determined what was the project that they belonged to etc.

This changes that requirement, and now each RFI will contain full reference to the project. Same with RFI responses, that will contain full reference to the RFI. We can do that, but then the question is, what's the benefit of doing that?

From the description above it seems you want to be able to share RFI Responses via Email. That's running counter to the idea that we would use GDrive/Box/Resilio to manage these. There is no need to email anything if it gets shared automatically via gdrive. It's the person's adding a response responsibility to add it to the right folder, rather than the receiver's to know what folder the response was intended for. Why are we changing this approach?

gschleusner1972 commented 4 years ago

Not changing approach... The core ideas have always been that Transport, Edit and Communication should be thought as separateable concepts. I don't think I knew how to express it this way and so maybe it didn't come across. I don't think the desktop app needs to change outside of adding this data... its when you think about that the desktop app might not be the only way to easily to add data or add responses that you start to take redundant approaches. For example let's say that for a firm or a project a solution to security is to use email to send individual questions because you don't need a party to have all the data. You will have to break the data up and allow it to be reassembled. Or maybe on a phone it's easy to read in a file system approach but you don't have the same methods or tools to write back the responses etc. Make sense?

gschleusner1972 commented 4 years ago

I know some of this looks odd...but the goal is just as much to spread a tool approach as a distributed data approach. @ksobon

ksobon commented 4 years ago

Yeah, I know what you mean, but I am a little blurry on how is that needed right now. If we want to use email to reply to RFI's why now just build an Outlook plugin that writes the RFI file to GDrive as we intended before, or synchs Email contents to the desktop app?

I don't see an issue with adding that extra data, and perhaps I shouldn't argue here without understanding the full picture. I just like to know why I am doing something, just in case I don't think it's an optimum solution.

Now on the subject of adding these GUIDs, the actual reason I am asking is because I went to certain lengths to program this sucker up where RFI doesn't have information about its project in the actual JSON file. If I knew that I will be able to store the project GUID in there, then I could have saved myself a bit of time trying to work out what project an RFI belongs to based on its file path etc. It was a hustle, easily solved by adding ProjectID to RFI, or RFI Id to Response etc.

Cheers!

gschleusner1972 commented 4 years ago

You are right to be annoyed. Me not including this in my mockup gave the wrong impression that it wouldn't be useful to have in the future... I looked at some my older ones and it was indeed there... it was part of the link structure ... where the links included the UUID of the parents etc. Sorry about that. Its not necessary at this moment so don't spend time on it until you feel comfortable with the why... not just that I said it was a good idea.

On Mon, Sep 21, 2020 at 1:33 PM Konrad Sobon notifications@github.com wrote:

Yeah, I know what you mean, but I am a little blurry on how is that needed right now. If we want to use email to reply to RFI's why now just build an Outlook plugin that writes the RFI file to GDrive as we intended before, or synchs Email contents to the desktop app?

I don't see an issue with adding that extra data, and perhaps I shouldn't argue here without understanding the full picture. I just like to know why I am doing something, just in case I don't think it's an optimum solution.

Now on the subject of adding these GUIDs, the actual reason I am asking is because I went to certain lengths to program this sucker up where RFI doesn't have information about its project in the actual JSON file. If I knew that I will be able to store the project GUID in there, then I could have saved myself a bit of time trying to work out what project an RFI belongs to based on its file path etc. It was a hustle, easily solved by adding ProjectID to RFI, or RFI Id to Response etc.

Cheers!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ksobon/MagnetarCA/issues/1#issuecomment-696261306, or unsubscribe https://github.com/notifications/unsubscribe-auth/AICA2F2US5Z66US3PIVCT3TSG6E6ZANCNFSM4RUW7CYQ .

gschleusner1972 commented 4 years ago

That said the other thing that came to mind that is related to this... is clearly the paths are not correct across all devices and you are treating them as relative but saving them as absolute. Maybe this is the place to think about adding "Typed Links" with the UUID in them? Something to think about and discuss when we get a chance to connect

On Mon, Sep 21, 2020 at 1:37 PM Greg Schleusner gschleusner@gmail.com wrote:

You are right to be annoyed. Me not including this in my mockup gave the wrong impression that it wouldn't be useful to have in the future... I looked at some my older ones and it was indeed there... it was part of the link structure ... where the links included the UUID of the parents etc. Sorry about that. Its not necessary at this moment so don't spend time on it until you feel comfortable with the why... not just that I said it was a good idea.

On Mon, Sep 21, 2020 at 1:33 PM Konrad Sobon notifications@github.com wrote:

Yeah, I know what you mean, but I am a little blurry on how is that needed right now. If we want to use email to reply to RFI's why now just build an Outlook plugin that writes the RFI file to GDrive as we intended before, or synchs Email contents to the desktop app?

I don't see an issue with adding that extra data, and perhaps I shouldn't argue here without understanding the full picture. I just like to know why I am doing something, just in case I don't think it's an optimum solution.

Now on the subject of adding these GUIDs, the actual reason I am asking is because I went to certain lengths to program this sucker up where RFI doesn't have information about its project in the actual JSON file. If I knew that I will be able to store the project GUID in there, then I could have saved myself a bit of time trying to work out what project an RFI belongs to based on its file path etc. It was a hustle, easily solved by adding ProjectID to RFI, or RFI Id to Response etc.

Cheers!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ksobon/MagnetarCA/issues/1#issuecomment-696261306, or unsubscribe https://github.com/notifications/unsubscribe-auth/AICA2F2US5Z66US3PIVCT3TSG6E6ZANCNFSM4RUW7CYQ .

ksobon commented 4 years ago

Well the Settings.json holds an absolute path to the Root of any project that user opens/creates in MagnetarCA. That is the only path is being stored in JSON files. Everything else is just parsed from the directories. That's how its able to work for you and me, even though the same project is located in different places on a drive. There is no relative path used here (not exposed to the user at least). I do keep a reference internally, but that's a different topic.

ksobon commented 4 years ago

@gschleusner1972 having ParentId property, how does that affect our current workflow for adding an existing Company? So at the moment you can create a new company, or add an existing one by pointing to JSON file on a drive. The idea was that we would have some overlap between different projects, and wanted to import some assets to make it faster to setup a new project.

So, the question is, do we reset the Id of the imported company? Do we set its ParentId to that of the project that its being imported into? Perhaps we keep the company id untouched, but reset its parent id? Thoughts?

gschleusner1972 commented 4 years ago

The parentID wouldn't make sense for that field, but giving a Company a UUID would. On the RFI or Responce i'd then just store the UUID ID under a "ContractorUUID, ClientUUID" field. This way you can reuse it but you know in what role the company was being used on this RFI.

Per your point about making an Outlook Client, I agree. The reason you want the data to be self describing so you can do something like this; (Not saying we are doing this now... but this is the kind of quality of life stuff people really would like to have.. removing steps from human to have to translate)

When we meet next time I'll show you what I'm thinking about for capturing emails to start this process from forign systems. At that point I'd start to socialize this effort with HOK.

  1. Reviewer Emails Response to "Konrad"
  2. A Magnetar, Microsoft Office 365, GraphAPI service reviews the income email ...
  3. The Magnetar Service sees the response file and automatically routes it to the project folder and registers it on the project
  4. The Magnetar App alerts the users to a new item in the app
  5. No Human invention has been required to path the response to the right location on the project

Greg

On Mon, Sep 21, 2020 at 5:07 PM Konrad Sobon notifications@github.com wrote:

@gschleusner1972 https://github.com/gschleusner1972 having ParentId property, how does that affect our current workflow for adding an existing Company? So at the moment you can create a new company, or add an existing one by pointing to JSON file on a drive. The idea was that we would have some overlap between different projects, and wanted to import some assets to make it faster to setup a new project.

So, the question is, do we reset the Id of the imported company? Do we set its ParentId to that of the project that its being imported into? Perhaps we keep the company id untouched, but reset its parent id? Thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ksobon/MagnetarCA/issues/1#issuecomment-696377198, or unsubscribe https://github.com/notifications/unsubscribe-auth/AICA2F7W5IM5XQXYNIZWQNDSG66APANCNFSM4RUW7CYQ .