Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need for a unique and permanent identifier of channels #29

Open
wm75 opened this issue Jun 6, 2024 · 8 comments
Open

Need for a unique and permanent identifier of channels #29

wm75 opened this issue Jun 6, 2024 · 8 comments

Comments

@wm75
Copy link
Member

wm75 commented Jun 6, 2024

atm, we're keeping track of where things got posted and work out where to post new items through the name attributes in the plugins.yml, so this implies that these names will never change.
At the same time we're using these as "labels" to hint at their meaning, and that means we would perhaps want to change them (for example there might be more than just one "slack" channel in the future.

So it would be good to separate the "id" and "label" concepts and never change ids afterwards.

@bgruening
Copy link
Member

nice catch, also also document that the ID needs to stay stable in our examples and documentations.

@arash77
Copy link
Collaborator

arash77 commented Jun 6, 2024

So, do we have to address each social media channel with an ID instead of a label?

@wm75
Copy link
Member Author

wm75 commented Jun 7, 2024

Not completely sure about this.
I would say the name/label will be more user-friendly and the processed_files.json could still record the id.
The disadvantage is that the content of /posts might contain headers with outdated names/labels, but that would make it just a bit harder to trace back where a given post was sent to, not impossible.

@arash77
Copy link
Collaborator

arash77 commented Jun 10, 2024

I was thinking about this and I got a new idea that I am unsure if it fits our situation.
what if we have this config for the plugins.yml for example:

- name: slack
  class: slack.slack_client
  accounts:
    '1':
      enabled: true
      config:
        access_token: "$SLACK_ACCESS_TOKEN"
        channel_id: "$SLACK_CHANNEL_ID"
        max_content_length: 40000
    '2':
      enabled: true
      config:
        access_token: "$SLACK_ACCESS_TOKEN2"
        channel_id: "$SLACK_CHANNEL_ID2"
        max_content_length: 40000

We can therefore call them in the post configs media, for example, slack#1 and slack#2.
Also the same format in processed_files.json: {"slack#1": true}
This way we combine the label and id, and make sure that the name won't get changed.
What do you think about this? @bgruening @wm75

@wm75
Copy link
Member Author

wm75 commented Jun 13, 2024

Looks neat, but I'm still worried about poorly chosen names that you'd later like to change.
Like say, we now set up an "account" that posts to a certain matrix room as "usegalaxy-eu" and name it only after the room. But later .org decides that they would like to post to that same room under a different identity, so you would like to include "eu" in the name of the existing account. Or you decide to rename the room at some point and would like to rename the "account" accordingly.
If you decide to change the name you'd still invalidate the processed_files.json.

@arash77
Copy link
Collaborator

arash77 commented Jun 13, 2024

@wm75 So, something like this would be better?:

- name: slack
  class: slack.slack_client
  accounts:
    '1':
      name: 'usegalaxy-eu-eu'
      enabled: true
      config:
        access_token: "$SLACK_ACCESS_TOKEN"
        channel_id: "$SLACK_CHANNEL_ID"
        max_content_length: 40000
    '2':
      name: 'usegalaxy-eu-org'
      enabled: true
      config:
        access_token: "$SLACK_ACCESS_TOKEN2"
        channel_id: "$SLACK_CHANNEL_ID2"
        max_content_length: 40000

The label would be slack.usegalaxy-eu-eu and slack.usegalaxy-eu-org.
The ID that will be used in processed_files.json would be slack#1 and slack#2.

@wm75
Copy link
Member Author

wm75 commented Jul 16, 2024

An additional aspect that we discussed yesterday is that we should probably record commit IDs of what got posted where. An example where that could be useful is #72 where one would like to modify the post content for better formatting on bluesky, but that same content has already been posted to other platforms.

Alternatively, we could of course enforce that a new file must be created in such cases.

@bgruening
Copy link
Member

I guess a new file is less black magic and more transparent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants