开云体育

jeffp,

Lena wrote:

Can you rename the subgroup before deleting it?

That's a good point, and I should have thought of it. In Yahoo Groups (and no doubt Groups.io) renaming a group does not reserve the old name.

If the same holds true for Groups.io subgroups then you could rename the subgroup to something arbitrary before deleting it. That way you can pick any arbitrary name to make non-reusable, leaving the desired name free for reuse.

Shal

That is a good point, but it's too late in our case. We deleted the group already, with a series of consequences that we didn't anticipate (and which I have documented in another post here on GMF, soon to be approved, I hope). Those consequences have completely convinced me that the use of subgroups - at least as currently implemented - will not work for us, and thus the renaming issue isn't one I have to worry about, even though we should have thought of it.

That said, I'd need to look to see if there is even a way to rename a subgroup. Honestly not sure of that. ? :)

--jeffp

Hi All,

Today I have a cautionary tale. As some of you might recall, I looked into subgroups as part of our coming migration, hoping to solve some issues with hot topics and other things in our neighborhood group. Alas they aren't in a state where they help with that for us, because we can't move messages (and threads) between groups easily and keep replies from showing up in the wrong place. So, unless that changes, subgroups are a no go for us.

Then I discussed an issue about deleting a subgroup, where Mark told me that deleting a subgroup does not free up the subgroup name for reuse unless you specifically ask for them to free it for you. OK. Such is life.

Then we decided to delete the subgroup I'd created as a test. It was confusing our beta testers about what address to send to, among other things.

It turns out that subgroup deletion has impacts, let me tell you.

I'd created a bunch of pages in the wiki - our group FAQ - and crosslinked them in quite a few places. Imagine my surprise when all those links broke.

Looking at them, I discovered that the URLs in use for the links were all invalid because they'd been created while the subgroup existed, but now that it didn't exist anymore the URLs I needed are different. Example:

• ?- a URL created when the subgroup existed. (This doesn't work anymore.)
• /g/95033talk/wiki/95033talk-FAQ?- the corrected URL needed after the subgroup was deleted (or before any subgroups are created).

I suggest everyone think LONG and HARD about creating any subgroups if you have links anywhere in your system - in messages or the wiki, at least - because if you do, your first subgroup will break all those links. And if you delete all the subgroups you create, you'll have to fix all those links again. I learned this the hard way. Only about 20 links to fix in my case, that I know of, so far. YMMV.

I suggest to the developers that there is something wrong with the existing subgroup scheme in this regard. No one should expect the links in their wiki pages to break if they create their first subgroup, or delete their last one. Similarly with links between messages in the message archive. There has to be a better way for subgroups to work.

And while I am on this rant - sorry! - this wiki is very limiting. No images? Real URLs for internal links rather than the much simpler page name schemes used by most wikis? Without wanting to make even more work for myself, is there anything that can be done about that?

--jeffp

One of my organizations has a wiki on Google Sites. Is it possible to
transfer a wiki?

Can two Yahoo groups be transferred and combined into one Groups.io?

Are there any directions for using the Wiki?

And does it count in the files storage limitation?

data: doesn't consume storage where the 1 GB free limit is.

Lena wrote:

Can you rename the subgroup before deleting it?

I'm also curious about the image showing in full-feature digest messages. Is it shown at full size, inline in the message as sent, or is it shown as a thumbnail that one can open?

?It is shown full size. ?

Here is one of the facebook integration photos that came in daily digest. Sorry but I can't find any of the test photos I did. Integration may be different as it appears a normal size on line but when posted to groups.io even in messages it is massive:

You can see that even with my large laptop the whole picture needed scrolling to see. ?Made members using cell phones to view the messages loose their minds.?

Don't worry, we got it fixed by resizing the photos before they got uploaded to Facebook. Now they appear like this in the daily digest:

Yes it would be helpful if you set up a test, that way we'd all know what to expect when photos are added either remotely or inline.?

I get this forum via Fully Featured Daily Digest and would be happy to report (do you want screen shots?) what I see. ?All I know for sure is that pictures (not from photo albums) from websites remotely posted (copied from webiste and pasted into message) do show up in daily digest. ?How they appear in other message options, (we don't allow attachments/photos in messages) is hit and miss as I was testing various things, with so many other things on the go. ?

As a test, here is an inline photo that is pretty large. I did no resizing. ?

--
-LeeAnne

?Archivist

data: This scheme is newer, and tells the user interface that the image
file is encoded right here in the message body (within the <img> tag),
not in a separate file.

One could argue that the Max Attachment Size setting shouldn't affect this
scheme, because the data: scheme is technically not an attachment. But the
counter argument is that ignoring the data: scheme defeats the purpose of the
attachment limit: to reduce the data consumed by the message.

having that subgroup
around - but locked down - is going to cause confusion for our members.

jeffp,

Mark answered my submission to [email protected]. His answer was very
concise:

We don't currently recycle group names except when asked. If you run
into this, you can email us and we're recycle a given name for you.

That's not at all the answer I would have expected. Or rather, I would have expected that answer for the primary group names, but not the names of subgroups.

However I just verified it in my test group.

I don't see a reason for this restriction on subgroup names. I think it must be just an artifact of the subgroup implementation being largely the same as primary group implementation.

Shal

I agree that it is a bit of a surprise. And as I work with the group we're planning on transferring soon, I keep thinking that having that subgroup around - but locked down - is going to cause confusion for our members. I need to talk with the other moderators about it, but we may delete it and then ask Mark to make the name available to us again in the future.

It seems that - at least in most cases - subgroups would be created only by owners or moderators, not regular users. In such a case, the deletion of a subgroup should be a relatively rare thing, and not something done lightly. Making the names available again in that case seems rational, but maybe it's a challenge in the system as it is implemented.

In any case, we'll get by. It's just not a place where this system follows the principle of least surprise.

Mark answered my submission to [email protected]. His answer was very
concise:

We don't currently recycle group names except when asked. If you run
into this, you can email us and we're recycle a given name for you.

Before I make any suggestion/comment about this on beta or report a bug, I
want to make sure I'm not missing something: shouldn't clicking on a hashtag
on the home page take you to the messages with that hashtag, instead of just
to the messages list??

Plain Text messages

A plain text message cannot have an image (or any other formatting)
contained within the message body. It can however carry attached files,
and files containing photos or other images can be carried that way.

HTML (formatted) messages
...
cid: (content ID). ... It tells the receiving email user interface that
the image is contained in an attached file within this email message,
and the ID tells it which attached file is used for this <img> tag.

data: This scheme is newer, and tells the user interface that the image
file is encoded right here in the message body (within the <img> tag),
not in a separate file.

http: (Hyper Text Transfer Protocol). This scheme tells the receiving
mail interface to fetch the image file from a server on the internet.

Besides the home page, it also behaves the same on the Topics view and Messages view.

Yes, right, I see that now. I'll add a p.s. to my bug report and cc you.

J?