SSSP pseudos not listed in verdi group list

[chrisjsewell]

Bit of an odd one; if you list the groups then the SSSP groups don't show up, despite them being present and accessible by label:

$ verdi group list -a
  PK  Label              Type string    User
----  -----------------  -------------  ---------------
   2  20200625-161551    core.import    aiida@localhost
   4  20200625-161624    core.import    aiida@localhost
   5  sg15-oncv-1.1      core.upf       aiida@localhost

$ verdi data upf listfamilies
Success: * SSSP_1.1_efficiency [85 pseudos]
Success: * SSSP_1.1_precision [85 pseudos]
Success: * sg15-oncv-1.1 [69 pseudos]

$ verdi group show SSSP_1.1_efficiency
-----------------  -------------------
Group label        SSSP_1.1_efficiency
Group type_string  core.upf
Group description  SSSP 1.1
-----------------  -------------------

Note, the fact the ONCV pseudos do show probably spawns from the different way both are imported:

ansible-role-aiida/tasks/aiida-pps-oncv.yml

Line 36 in f50e41c

shell: "{{ aiida_venv }}/bin/verdi data upf uploadfamily {{ aiida_data_folder }}/{{ pp.folder }} {{ pp.name }} '{{ pp.description }}'"

ansible-role-aiida/tasks/aiida-pps-sssp.yml

Line 3 in f50e41c

shell: "{{ aiida_venv }}/bin/verdi import -n {{ aiida_data_folder }}/{{ pp.file }}"

Not sure if this points to a bug in this role or a bug in aiida-core?
cc'ing @sphuber

PS this may also relate to #36

[sphuber]

What is the user of those groups? Can you run with verdi group list -a -A? It might be that they are not of the current default user aiida@localhost and then they won't show up.

[chrisjsewell]

Ah thats the one cheers!

[sphuber]

Yeah, the concept of different users is not used a lot and so not very prominent in the API and so often leads to these confusions. Not sure how we can improve this

[chrisjsewell]

$ verdi group list -a -A
  PK  Label                 Type string    User
----  --------------------  -------------  --------------------------
   1  SSSP_1.1_efficiency   core.upf       [email protected]
   2  20200625-161551       core.import    aiida@localhost
   3  SSSP_1.1_precision    core.upf       [email protected]
   4  20200625-161624       core.import    aiida@localhost
   5  sg15-oncv-1.1         core.upf       aiida@localhost

maybe ideally both should be installed in the same way, because thats a bit confusing

[chrisjsewell]

the concept of different users is not used a lot and so not very prominent in the API and so often leads to these confusions.

yeh it probably should be mentioned in the documentation somewhere, particularly in the groups section. It feels like User would be better termed Creator or something, at least for verdi group list, and maybe all users should be shown by default

[sphuber]

$ verdi group list -a -A
  PK  Label                 Type string    User
----  --------------------  -------------  --------------------------
   1  SSSP_1.1_efficiency   core.upf       [email protected]
   2  20200625-161551       core.import    aiida@localhost
   3  SSSP_1.1_precision    core.upf       [email protected]
   4  20200625-161624       core.import    aiida@localhost
   5  sg15-oncv-1.1         core.upf       aiida@localhost

maybe ideally both should be installed in the same way, because thats a bit confusing

Well, that is a more fundamental question though. Here we are importing nodes that have been created by someone. It seems logical to not change the attribution just by importing them. In that case the whole concept of having a User attached to each entity would be useless. Note that this does not just apply to groups, but also nodes, computers, comments etc. Once we have aiida-pseudo the problem will go away, since whoever is running aiida-pseudo install will create the nodes, so they should belong to the default user.

yeh it probably should be mentioned in the documentation somewhere, particularly in the groups section. It feels like User would be better termed Creator or something, at least for verdi group list, and maybe all users should be shown by default

This would be quite a big change though, because User really is just the database model that is being used for this purpose. We could change the naming to creator in the interface in certain places, but it would be a lot of work and potentially backwards incompatible.

[chrisjsewell]

It seems logical to not change the attribution just by importing them

yep agree, we should preserve the "author" of objects

IMO, semantically we are using User the same way that git assigns a user to a commit: you're still storing users as a table in the DB, but e.g. when you do git log it shows the user under Author.
Also, we are mainly assigning User to objects just to record who created them, not who can use them, so that's why it doesn't make sense to me to be hiding them in verdi group list