Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - negg

Pages: [1] 2
1
Older versions / Group Interface, strange permission behaviour
« on: September 07, 2009, 12:09:42 pm »
I noticed some strange behaviors about the group interface and permissions:

- when a group has complete rights for a workspace the members seem to be able to do all they could if they were assigned individually via workspace->permissions. But there the rights are shown with a checkbox besides the user's name, but no checkboxes for "All", "Can read messages",... checkboxes. This suggests the user has not rights there (which is wrong).
I would suggest to NOT show any individual rights for the user in the workspace->permissions dialog, because this suggests the rights there overwrite the group rights or something else. I think the user's name should be mentioned there with a comment "Group rights from group XY apply for this user".

- when the checkbox beside the name of a group member in the workspace->permissions dialog is cleared the group is removed from the workspace completely, which is not what I expected. But I think it is wrong to show the user with rights here at all (see above) so this "error" would disappear automatically when the individual rights checkboxes are removed for group users in the workspace->permissions dialog.

- when a group has complete rights for a workspace the members can do all they could if they would be assigned individually, but they still don't show up in the modify subscriber interface.

So if this is intended I don't get the point :-) if it is not, maybe you could provide a quick hack that makes the permissions for group users in the workspace->permissions dialog identically (so that they show up in the subscribers dialog). Otherwise I would need to change a dozen of users in a dozen of projects out of the group back into individual assignment... :-(


2
Older versions / Re: Search silently ignores words with less than 4 letters
« on: September 02, 2009, 01:32:05 pm »
Right, see what you can do, I know searching with mysql is not that easy all the time. But in any case the user should know what's going on in order not to lose trust in the search (as our users partly do already).

IMHO a good way would be to add an extra line of text when someone searches two-letter words "the search text you entered is too short, please use at least four characters".

3
Hi,

this bug is fixed for next release,
if you want to fix it in your installation you have to replace line 165 of /application/controllers/FeedController.class.php with these lines:

Thanks, that worked fine. Looking forward to the next version, the changelog must be huuuuuge :-)

4
Older versions / Milestone display not updated for subtasks
« on: September 02, 2009, 09:53:09 am »
Ok, sorry for posting all those bugs, but today seems to be bugday:

When you assign a Milestone to a parent task within the in-list editing form and you tick "Apply to subtasks", and then you click edit on the subtask to check if that worked the Milestone field for the subtask is still empty.

Normal users would believe that it did not work. I found out that it's only an update problem: after reloading the task list the milestone appears on the subtask, too.

5
Older versions / Search silently ignores words with less than 4 letters
« on: September 02, 2009, 06:32:13 am »
The help (http://wiki.opengoo.org/doku.php/search) does not elaborate on how short searches are handled. Looks like all search words with less than 4 letters are ignored.

Is this correct, then the search should tell the user about this behaviour. Even better would be to let the search happen up to min. 2 letters, because especially in software projects 2 letter abbreviations are not so uncommon. I know this might collide with mysql's indexing, but I think the necessity is there.

EDIT: a string like "IE6/7/8" can also not be found. Is the / confusing the search?

6
Older versions / Unchecking "Sub.Ws" Checkbox in ical subscribe does nothing
« on: September 02, 2009, 05:41:51 am »
I have a workspace with numerous subworkspaces with their own calendar entries. I only want to import events in the main workspace, so I unticked "SubWs" besides the ical subscribe button. The URL changes from "...isw=1" to "...isw=0" which I believe is the parameter for subworkspace integration.

But that does nothing. The ics files delivered are exactly the same. Did I get something wrong here?

7
Older versions / Enter key works differently in "Assigned To" field
« on: September 02, 2009, 05:21:34 am »
In the task interfaces pressing the enter key in the "Assigned To" field leads to different actions, which is very confusing:

  • In the "on the fly" edit dialog (after pressing "edit" on the right in the task overview list) when the cursor sits in the Assigned field and you press Enter the displayed name is simply "accepted", nothing else happens. Thats expected.
  • In the full featured edit dialog (when you press on the task headline and then "Edit" in the task detail page), pressing Enter there in the assigned field submits the complete task. This is not expected and leads to numberless accidental submissions.

Can you provide infos how to patch that, please, if possible? Would like to stop that behaviour as soon as possible.

8
You might be right, maybe I changed the permissions, though I don't think this is too probable. We changed from a personal to group permissions, and all my users are in the same group having access to all projects.

I don't think it makes sense, though, to have someone subscribed to a project he does no longer belong to or have permissions to. Would expect all subscriptions to be removed when permissions are removed. Or at least he should no longer be displayed as "subscribed" in the overview.

I will keep an eye on this and get back here if I find something unusual! Thanks so far!

9
When someone is subscribed to a task and you open that task (e.g. to unsubscribe him) he does not show up in the interface "Subscribers" (the one with the big buttons).

10
(I consider this a bug, because I cannot think of a reason to do it that way...but maybe its a feature someone can explain to me...)

When a subscription is changed this triggers a notification email. IMHO this should not happen, because changing subscriptions is an act of internal administration, not a substantial change to the task/event.

11
This should be a matter of minutes for a developer with insight (I would do it myself if I understood the structure of the opengoo php better):

In the Group Administration dialog only the login names of the users are displayed. To make identification easier one would need the real names or even better the normal user select module like it is used in the "Subscribers" dialog.

Anyway, real names rule :-)

12
Makes subtasks nearly useless: when a task detail view is opened from a task list with expanded subtasks and you click on "back", the list view is collapsed completely! So you have to expand all the branches again to get to the view you had before.

I think the concept of opening tasks with a internal request instead of a real link makes it necessary to store the expand/collapse state of the list.

13
When grouping the task list by tag every task gets a grey bar on the left on mouseover and can be dragged over another task to make it a subtask. Fine!

But: when grouping by "workspace" this does not work. Took me some time to find out what the reason was that it didn't work...irritating.


14
I have subscribed to the rss feed of a workspace. When I open one of the tasks that come in to the rss feed as changed by clicking on the provided URL in the form:
https://address.is.invalid/index.php?c=task&a=view_task&id=334

...the workspace the task is assigned to is neither opened in the workspace list on the left nor displayed in the "Workspace" part of the properties box on the right.

If I then click "Edit" and there "Back" the workspace is shown on the right.

(Problem: this occurs only 80% of the time, can't find a rule when exactly this happens. But it seems to be more likely with tasks I never opened before.)

Makes it hard to find out what you are looking at when opening the task...

15
Older versions / Import of over-midnight events fails miserably
« on: August 12, 2009, 01:49:44 pm »
I just imported an event ics that went over midnight. The import went OK, the event shows up in overviews, but in the calendar the event is not displayed.

Seems to be because events that are over midnight can't be set. This is of course not good in itself, but until that is fixed/possible maybe the import could complete with an error or a hint that the event will not be visible until its end is set before midnight or the import could simply set the end to 23:59 and show a message that it did?

But in any case: PLEEEEEAAASE make events over midnight possible as soon as possible!

Pages: [1] 2