Should projects without an organization for a particular language be possible?

[KonradUdoHannes]

Currently there are projects in directus that don't have an organization if the language is set to en-US. For instance 2019-01-MAP. This causes problems for the using-data/projects route.

Accroding to our parsing logic this is currently not allowed and causes the build to fail. @friep @jstet Did something change here on the directus site, because the build succeeded previously. (We do have a working static build in prod)

If desired we could loosen the constraint to extract the organization name independent of the language. I think something similar is done in at least one other ocasion already.

[friep]

from a "data curating" experience, it would make sense to not require it because it won't be necessary to have this information for those projects that we "anonymize". Or we make them required but people can also just add in " " (a bit hacky but would mean we don't run into this problem). I think this would be better because otherwise it's also just very hard to keep track of "missing" data within directus ^^

[KonradUdoHannes]

I think the current status is actually fine. The root cause of my question ended up being an issue with permissions in directus. I'll therefore close this issue, because there is no problem.

[KonradUdoHannes]

Currently the published project 2021-04-KOB causes some trouble for the website build because it does not have an organization associated with it, which is currently not supported.

I think we need a systematic solution for cases like this because I expect this to be the case more often, particularly when it comes to open source projects, that are not done for a particular organisation. It also seems to be different from the (already covered) case of projects where the organization simply wishes to stay anonymous.

On first thought, I see three options to deal with it.

1. Allow for missing organizations and modify the project cards on the website to then simply omit the element. Given the current card design, I think this would still look fine. The disadvantage is that missing organizations would no longer come to our attention automatically (as with the build failure right now). Accidentally missing organizations would therefore potentially go unnoticed for a longer period of time.
2. Use CorrelAid itself as the organization for these type of open source projects, which I think is fair particularly when the projects are hosted on the correlaid github org account.
3. We agree on an explicit placeholder for projects that have no organization associated with it (Maybe a little more verbose then " " suggested above. For instance "NO ORG"). That way we could treat these projects individually but don't loose our sensitivity for actually missing data.

@friep what do you think

[friep]

there is a field is_internal which is true for the open source projects. Could you put a simple if else filter on the organization head based on it and put "Internal project" instead of the organization name? So basically 3. but based on a different logic.

Alternatively, i'm also fine with approach 2. i'd still use aforementioned field to replace the organization box in the subpage with a small info text what an internal project is (i can write this up if you need it but so far we don't have internal projects with subpages i think). would this be possible?

[KonradUdoHannes]

Sounds good. I'll start with the implentation of the is_internal suggestion and track it here #489. Then we can keep this issue for further discussions and to track different aspects of the topic, such as the subpages once they become relevant.

[jstet]

As project always need content in both languages, this should be the same for organizations imo

[jstet]

If this is not the case, build would fail atm. I'll just make the decision for now that this is desired behaviour

[friep]

agreed 💯